Systems engineering: bridging the gap

In a top-down design process, there is often a missing link between systems engineering and design implementation.

Performing large-scale system design and upgrades is a complex task. Traceability and synchronisation across all design levels is key to streamlining large-scale development programs. However, there is often a missing link between systems engineering and design implementation in a top-down design process.

Systems are ever-increasing in size and complexity. There are requirements that must be engineered, maintained, derived, allocated and adhered to; and constraints on performance, costs, time to market, power consumption, weight, etc. Systems engineering is a challenge that needs to address these factors throughout the design of system architectures. The outcome of this process is typically a set of starting points for the design of the sub-components, with interface descriptions, sub-constraints and derived requirements.

The main challenge is to have a focus on each component without losing the overview. Crucial system context information, requirements traceability for the system and (derived) component level, and the use of filtered views for handling system complexity are key. An easy transition to development of the system and guaranteed consistency are also necessary for success.

Decomposition of requirements and allocation to an architecture model

A systems engineering project typically begins with high-level requirements and optionally a legacy system that could be reused to some extent. The main task is to create an architecture with sub-components, each allocated to derived requirements to fulfil their share of the overall functionality, with as many hierarchy levels involved as appropriate. This structural decomposition is accompanied by a similar decomposition of the requirements, so that the constraints of each sub-component are sufficiently defined.

Non-functional requirements

Many requirements are referring to lifecycle issues or other non-functional constraints. Possible solutions have properties such as weight, cost, reliability, development effort and other data that need to fit these non-functional requirements — as well as their compositions — on each hierarchy level. Accordingly, a hierarchy of stereotypes has to be defined, representing each type of sub-component and capturing properties as needed, including the non-functional requirements mentioned above.

Functional requirements

Temporal performance constraints aside, functional requirements are typically not addressed specifically on the architectural level, other than getting decomposed into derived requirements in parallel with the system decomposition. Performing a complete analysis at this early stage is possible with formalised requirements, but due to the difficulty of getting a complete set of requirements and assumptions, this assume-guarantee reasoning is applied very rarely in practice and is not covered by this methodology approach. Instead, simulation is proposed on the component and architecture levels to validate requirements consistency locally as well as overall system behaviour.

Therefore, the ability to simulate the very same overall architecture model that was used to define components with their interfaces and interconnections is needed to avoid any mistakes caused by a rupture of systems engineering and design flow.

Handling complexity

By definition, systems are more complex than just the software or just the hardware, or any other segmentation of the system. Focusing just on parts of the system during any design activity is mandatory to not get lost or tangled in complexity issues. However, if important context information about the role of a component is missing, specification or design flaws become inevitable.

So, a suitable subset (view) of the system needs to be set up to understand a specific design or analysis concern, with only the minimum required context information — everything not relevant for the task at hand needs to be hidden.

While finding an appropriate view meeting the criteria mentioned above is demanding, it is typically not sufficient to have just one view for a sub-part of the system. Different perspectives of looking at the system require different views that are all overlapping: functional dependencies, organisational dependencies, bottleneck views, power consumption considerations, supplier dependencies, maturity levels, failure probability views, safety integrity level sections and so on. A complete understanding of a specific design or analysis concern requires quick switching among the huge number of different groupings and filters needed on the sub-systems.

Since all such different views on a system always need to be consistent, tool support is crucial to define and use such views.

The right tools

Due to the size and complexity of systems, classical approaches with drawing tools and spreadsheets to account for custom properties and corresponding analysis are no longer appropriate. The probability of consistency issues and problems caused by out-of-date data is just too high if there is no dedicated tool support to keep data together and consistent. This is even truer for any manual approach to creating something like a view of the system, focusing only on specific aspects and leaving out all the rest.

Thus, systems engineering tools or development environments for software and for hardware that provide solutions for the challenges and tasks outlined above are highly recommended.

*Jean-Baptiste Lanfrey has over fifteen years of experience in application engineering and control design engineering roles. He joined MathWorks in France in 2008 and worked with customers in the control design, physical modelling, automatic code generation, and verification and validation domains before moving to MathWorks Australia in 2013.

Image: ©stock.adobe.com/au/infografx