Functional Safety and Systems Engineering are two important topics in the development of mechatronic systems. At times seen as difficult and process-intensive, both topics are really not so hard to grasp at all. Last weekend the conference Munich Open Space offered a wonderful exchange.
In this article, find 7 insights into functional safety and 10 insights into system engineering, and get a few impressions of the Munich Open Space. Organizer was Colin Hood, who has been an integral part of the systems & requirements engineering community for thirty years. A German version of this article is available.
During three conference days with focus on Functional Safety, Requirements Engineering and Systems Engineering, we were able to gather our experiences and expertise in a small circle of under 30 people and learn from others. The Open Space format, as described in my PM Camp Dornbirn article (in German), turned out to be very helpful again in order to create precisely the agenda which offered the most benefit to participants.
The 45 minutes a session lasts is definitely time to dive a bit into the depths, but at the same time not get stuck in a single aspect.
The agenda of the Un-Conference is set up in the morning, when the participants present their session proposals. In doing so, a dynamic can arise where participants try to group topics not only in successive sessions, but also to group several proposals in one session. Engineers in particular want to constantly structure and standardize information. Resist this urge. Two participants may facilitate the same topic in two very different ways, and may have different facets in their heads. If enough time windows are free, it can be very valuable to leave the sessions separate.
Open Space on Functional Safety
Topic of the day: Functional safety, all about ISO 26262, IEC 61508 and related standards.
From the agenda for the Open Space Functional Safety I would like to take the sample of the three topics I proposed and facilitated:
- Agile and Functional Safety: At first sight it may seem agile development and the supposedly strict procedure for functional safety do not fit together well. But it does fit.
- Functional Safety – Function or Mindset: What is more effective – a department with specialists for functional safety or the Functional Safety Mindset for all?
- Modeling and Simulation in Functional Safety: What does modeling and simulation bring to functional safety?
It is clear that I did not attend just on personal matters, but because we at Elektrobit Automotive Consulting are working on these topics.
7 Insights to Functional Safety
- Functional Safety provides incremental procedures. That’s why there are all the different work products.
- Artifacts – that is, “Work Products” of Functional Safety – need to become part of the Scrum-Backlog. Because they are important to the product and are part of the system, they are to be treated like normal tasks or user stories.
- Scrum is sometimes more stringent than most processes that provide Functional Safety: During a sprint, requirements are fixed, to protect the team.
- Functional Safety works when everyone in the development process accepts that one does not apply Functional Safety at the end. Functional Safety means, first and foremost, clean, documented decisions and development, and that can and should be done by everyone.
- Functional Safety as the sole task of a staff department or an authorized representative leads to great friction loss. Functional Safety is everyone’s business.
- In modeling and simulating, “A fool with a tool is still a fool.” Without an idea of what you want to achieve, it will not help you, and you get bogged down.
- An application concept is required for each software tool. Wild hacking with tools is not helpful if you want an understandable and documented outcome.
Functional Safety is no rocket science. It is only unfamiliar to have to develop again cleanly and to prepare and document decisions cleanly. How to do that, you can learn.
Systems Engineering Camp
The Systems Engineering Camp was hosted under the GfSE umbrella, the “Gesellschaft für Systems Engineering e. V. – German Chapter of INCOSE”. Also at Systems Engineering Camp I proposed and hosted three more for Elektrobit Automotive Consulting:
- Value contribution or theater: Is what we do in systems engineering actually useful and necessary for the product?
- Executable specification – modeling and simulation: possibilities and experiences from 10 years of work with organizations of all kinds.
- Systems Engineering Bullshit Bingo: fun in systems engineering. Which empty phrases do we hear again and again?
10 Insights into Systems Engineering and Architectures
From these sessions and the others – see photo of the agenda above – some core statements stuck with me:
- The Systems Engineer is the
conductorJazz musician in the combo, who at the right time, integrates the right experts from different disciplines to develop the best possible system. The Systems Engineer does not have to have all the answers herself, but instead transports the system idea into the subject areas.
- It is necessary to distinguish between what activities in the field of systems engineering actually deliver value and what theater is. To this end I strongly recommend the book Back to work of Lars Vollmer (German).
- What is the contribution of value and what theater is can vary from project to project, from organization to organization. Example: Reports for completeness of requirements can be theater, or useful.
- 75% of all written and managed requirements are process theater and can be eliminated without restrictions. Colin Hood says, “If you have written down what the system should do, stop.”
- Specify exactly which architecture you think / suggest: system architecture, functional architecture, software architecture, hardware architecture or a completely different one.
- If you model and simulate at early stage, you will know sooner whether the functional architecture works or not. I’ve been preaching for over a decade with MATLAB and Simulink.
- Beware of dumb modeling and indifferent simulation. Only if you know the question, you can model well. See also point 5. There is a whole dissertation of mine about this to be read .
- Let’s not be so serious about ourselves in systems engineering – a round of Bullshit Bingo liberates with laughter. And we pay better attention to what we say in the project day by day.
- What are Bullshit terms and what not depends on the organization. Adjectives and acronyms are always hot candidates for hollow phrases.
- The difference between collaboration and confrontation when creating the architecture lies in precise language. It is a difference whether I want a CAN transceiver in the system architecture or CAN communication.
And these are just some things, there was much more.
Bonus: Rules for System Engineering Bullshit Bingo
- Take a sheet of any size and place 5 x 5 spaces.
- In each field put a concept, an acronym, a phrase representing a hollow phrase or is simply used too often or wrongly.
- Take part in a project discussion or a meeting and listen carefully.
- Each time one of the terms occurs, mark the appropriate field.
- When five items are marked in a vertical, horizontal or diagonal line, shout “Bingo”.
Our examples are shown in the photo above. As a discussion we simply emulated one and had a lot of fun.
As modification of the above ruleset, we split up into two groups, and put up our words on two sides of a large pin board. As it turned out, the two groups had very distinct sets of Bullshit phrases.
Open Space – open and yet purposeful
What are your experiences with Systems Engineering, or with Open Space Conferences? Let the other readers and me know and comment below!
Some impressions of the Munich Open Space, where between 20 and 30 people met on each day.
All photos: Joachim Schlosser Fotografie, Claudia Bösewetter.
Disclosure: I attended the event as an employee of Elektrobit Automotive Consulting. This post is not an official statement, it is my personal opinion.