Civil Engineers should possess some level of systems thinking, though they may not realize it

I did Electrical/Electronic Engineering in the 60s/70s, then a Masters in Control Engineering at Sheffield University.

They differentiated between systems engineering (i.e. concerned with e system as a whole) and control engineering  (i.e. the dynamics of the system)

We had one lecturer (a mechanical engineer) who told us that civil engineers understood the static forces on a finished box girder bridge but not the dynamics of building one. This was at the time when box girder bridges were falling down during construction.

Teaching civil and other engineers the importance of understanding the system as a whole is worthwhile and probably achievable.

Teaching nonlinear dynamics a different ball game altogether.

My PhD was in mathematical modelling of interacting biological systems. There was no way the surgeons and biologists could be taught enough to do it themselves.This is why, when it comes to the dynamics of complex systems the preference is for multi-disciplinary teams

The danger is that civil (or any other discipline) engineers might not know what they don't know, but should know.

As the saying goes "It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So"

quoteinvestigator.com/.../

Bernard, 

I agree.

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology. Therefore the way to explain the concepts is to use phrasing they recognise. My issue here is that I am not familiar with their phrasing since my background in definitely not Civils.

We were taught several aspects of maths using both mechanical and electrical terminology (sprung, mass damper, RCI circuit) to demonstrate the the maths was the same, just the application was different. I suspect its the same concept.

But beyond thinking as a whole system. I think that the Civils need to have a better grasp of why configuration control is useful (do you know what you were building that to), why requirements management when its done properly can add value, and why leaving it all the end (the right shift) is actually a bad thing.

Regards,

Mark

Peter Brooks said:

Was this taken before or after the discovery of the impact of the gut bacteria?

I started my PhD in 1970, which was well before any knowledge of the role of gut bacteria.

It was before much was known about large populations of interacting non-linear oscillators.

I modeled the electrical activity in the human small intestine which is created by ion activity across cell membranes.

My big finding was the way the oscillators would move into and out of phase and a cause a group of them to synchronise and move down the gut - a possible cause of peristalsis.

If you are interested, this is the paper that got published.

https://www.researchgate.net/publication/18699018_A_mathematical_model_of_the_slow-wave_electrical_activity_of_the_human_small_intestine

The whole area of intestinal dynamics is much more complex then we ever imagined and in now known as neurogastroenterology 

Peter Brooks said:

I would be very interested in knowing if you are currently employed in the medical field!

I never was. I've worked in a variety of engineering areas but I've always been interested in nonlinear dynamics. I am retired now but much of my latter work was on the dynamics of project and system development in government and large corporations.

Mark Tickner said:

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology.

That's a common complaint.

 I worked in government IT for many years and they have a totally different approach and language from engineers.

I found that you have to learn their language, they won't learn yours. Unfortunately things get lost in translation and there''s also the problem of the tender process.

A tender has solution requirements, but what is really important is the problem. Many vendors I have worked for were not much interested in the problem, only what was written in the tender. If the solution didn't solve the problem, it was the client's responsibility.

Which is why, when I talk about the system as a whole, I include the problem requirements as well as the solution requirements, they are two different, but connected domains.

e.g. it doesn't matter how good a bridge is if it is in the wrong place.

which is why I wrote this:

www.researchgate.net/.../260624035_Beyond_the_Zachman_framework_Problem-oriented_system_architecture

Hello Bernard:- So you are a OAP like me!

It appears that you are interested in Modeling Astronomical systems like Galaxies.. I see that the latest data suggests the center of our galaxy has less mass than previously thought and that means we have more dark matter on the outside of the arms. 

I am more interested in what is dark matter and dark energy, the strong force, virtual particles, the discontinuous nature of spacetime, and the rapid formation of early Galaxies.

Peter Brooks

Palm Bay 

P,S. Another one of my interests is the negative effects of drugs on the human body as one ages.  

.  

Thanks for that paper, another one for me to add to my collection regarding architecture frameworks.

This comes into one of those requirements management concepts, the stakeholder requirements should be written in the language of the customer and in the problem domain. Systems Requirements should be elicited from those stakeholder requirements and should ideally be in the solution domain and written in the language of the company providing the solution.

But.... depending on the complexity of the problem there may be a few more levels of system requirements in the problem domain before you get to the solution domain. And yes, depending on the nature of the project, you can have more abstract needs in the business domain that led to the stakeholder requirements. Some of this is handled in newer frameworks, such as the OMG UAF and Magic/MBSE Grid.

Customers/Stakeholders don't always play fair - and many a time I've seen stakeholder requirements in the solution domain and even a specific implementation!

So yes, Systems Engineers are used to providing that translation between different groups. But it is a good point for me to consider that I should be using their language to explain the concepts rather then to teach them my language. Its a bit like a STEM presentation, you are always told to keep your language to what they (the children) will have experienced and understand. But its much harder to do in practice.

Hello Mark:

Some years ago I had a problem with operating documents which were exclusively written by production engineers.

However they had to be used in training operators with a limited education, who couldn't understand the jargon.

I discovered that the US Navy had a similar problem where again the operating training documents were written by equipment engineers but they were way above the heads of the lower rank navy personal.

The US Navy developed a computer program that allowed the creator to lower the educational level to that of a 13 year old person by suggested replacement wording.

I attempted to get a copy of this application but it was government property.

Peter Brooks

Palm Bay  

Peter Brooks said:

The US Navy developed a computer program that allowed the creator to lower the educational level to that of a 13 year old person by suggested replacement wording.

When I consulted to the Australian government/public service on strategy I was told to make the reading age of written documents (as determine by MS Word) no more than 12 years. And short - 2 pages max.

It required more than word replacements - the sentences had to be short and simple.

Bernard

The provision of clear, easy to follow instructions is an art in itself, and an under-rated one. This is not really a system engineering problem, its wider than that - you only have to look at almost any piece of UK legislation.

The campaign for plain English has been railing against this for years, and publishes its worst examples of golden bull...

If you wish to use a computer program to proof check things and don't mind java, there is

https://www.plainenglish.co.uk/drivel-defence.html

Mike

From both Bernard and Mike's points, this is why I try to encourage engineers to get involved in STEM work, particularly in primary schools. It is fantastic training in getting your point across clearly (and, incidentally, in holding an audience's attention).

This is all great fun in functional safety documentation. On the one hand the safety evidence has to be written to a legal standard of preciseness and completeness, which frankly can sometimes make it, at the very least, tedious to read. On the other, in giving formal written safety instructions it is as you've all said above - they must be brief, clear, and intelligible to all - including non-native speakers. It's been interesting seeing the rise in appreciation in the safety community that old process of saying "we covered that by writing it down" is not only not adequate, it can even make the situation worse. One that particularly winds me up (and winds the Office of Road and Rail up too) is signage at level crossings - past projects have tried to cover themselves by adding huge numbers of verbose signs, which we know are simply not going to be read, and even if they are can be confusing.

ah yes

Beware 3 eyed alien space craft landing in field, low loader grounding risk, fence and historic railway....

But I always liked the idea of a switch in the car for waving a flag. Its actually wipers.
Mike

ah yes

Beware 3 eyed alien space craft landing in field, low loader grounding risk, fence and historic railway....

But I always liked the idea of a switch in the car for waving a flag. Its actually wipers.
Mike

Hello Mike:-

You obviously don't remember when cars used to have a right or left signal arm indicators that used to raise up from the side of the car body,  controlled by the driver when turning.

Peter Brooks

Palm Bay 

trafficators - I've seen them, I'm far too young and never driven a car with them ;-)

Seemed to spend a lot of time getting stuck or bent/ unbent if i recall correctly, but those cars were old even then. My parents cars always had 'winkers' as we used to call the orange flashing lights..

Mike.