Systems Engineering, What? Why? How?
The intent of this post is to provide an insight into the world of the systems engineer that is used to working on large embedded projects. Meaning engineers that design and develop products that fly, move on tracks or wheels and float, or in some cases submerge. It is a summ
What is it?
Systems engineering spans all the disciplines involved in developing a product. It provides the means to specify the parts of the system that are implemented in the different engineering disciplines, electrical, mechanical, software, hardware, chemical etc. Systems engineering is applied across all sorts of domains, aerospace, rail, automotive etc.
Despite the fundamental differences between the products produced by these domains they way that they are produced is relatively similar and use many common practices.
Systems engineering captures these practices and deploys them to improve the development process for the products that are actually produced. The people that deploy these practices are known as Systems Engineers. They tend to be engineers that have a high level of experience in at least one discipline and expand into the other disciplines. This broadens their understanding of how the disciplines interact and the design constraints that control implementation. This gives them a more holistic view of how systems need to be specified and moves them above the implementation.
Why do we do it?
The nature of products that companies are producing is changing. They are becoming more and more complex due to the increased functionality that we, as customers, demand from companies. The most common way of realising these new features and functionality is invariably software. It provides the flexibility to change the characteristics of a product much easier than if you use purely mechanical means. This is what is meant by the idea of the Software Gearbox, change functionality without changing physical components. Producers add value to the product by adding more functionality via software. Even though software is becoming increasingly important to products the ability to understand the affects software has on the other domains is still important.
The increased complexity in itself is an issue; there is a need to understand requirements and the effects of the emergent behaviour of the system. Other issues that arise are the need topics like improve safety analysis, improve security and comply with safety regulations.
Systems engineering then becomes the process of understanding the requirements properly and making sure that the resulting product is developed on time, to budget and that it functions as expected by the customer. The key approach to being able to achieve these objectives, irrespective of the methods used - be it incremental, agile, or waterfall - is to make sure that the requirements are well understood by all the people involved. Getting the requirements right at the beginning reduces the amount of rework at the end of the development cycle when the product is going through integration tests.
How do we do it?
The way that we help our customers develop products in IBM Rational is through the practice of Model Based Systems Engineering (MBSE). A structured approach that helps users understand requirements better as they develop models that express those requirements.
The models become a stake in the ground for our understanding of what the system is expected to do, and then they can be used to communicate that intent to other engineers who may have a different interpretation of the requirements.
This is a much more cost effective way of understanding a systems behaviour and removing errors as you are working on a virtual prototype. If done correctly, using the cont
This approach can significantly reduce the time taken to develop products as the combination of understanding requirements and using models helps with collaboration between teams, improving communication, and removes errors before the test cycle starts. By doing this continuously, each piece of existing behaviour is revalidated with the next set of behaviours as they are added. This can dramatically reduce costs by improving productivity. One of the other benefits of this approach is that it provides a complete traceability graph from the topmost system requirements to how they are implemented in the software. This is important as it allows true impact analysis to be carried out when examining the effects of change to the requirements at any level of hierarchy in the model. Something I referred to in my previous blog “Lea
The IBM Rational toolset that supports this approach consists of IBM Rational Doors, Rhapsody, Quality Manager, Test Conductor, Team Concert and the Rati
Thanks to Barclay Brown who provided many of the slides in my original presentation material.
Please feel free to contact me on Twitter @bleakleygj if you have any questions or comments.