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/.../

Hello Bernard:-

I was very interested in your comment about doing your PhD in Mathematical modelling of interacting biological systems.

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

With the rapid rate of finding new biological (feedback) pathways -- According to the medical journals I read every day (JAMA, NEJM etc) they announce one new significant pathway nearly every week- I think that it must be an impossible task to keep modelling up-to-date.

Then there is the problem associated with long term effects of external factors (examples taking medicines) on biological systems. I try and keep up with the negative effects of commercial medicines (FDA black box warnings) which are sometimes very important (example a very highly requested drug which can result in thyroid cancers).

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

Peter Brooks

Palm Bay 

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

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

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

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

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 

Hello Mike:

Regarding worst examples of golden BULL.

Have you ever listened to the audio recording by Peter Sellers - Party Political Speech (1958)- on youtube?.

By the way I used to attended some BBC recordings of the GOON SHOW in my youth.

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.