Systems Engineering

A Note To The Reader

This section describes how Systems Engineering is applied within Saab.

Systems engineering has emerged as the engineering domain for establishing and communicating an organisational consensus regarding the definition of the desired properties of the system from an operational and technical perspective in a structured manner.

The objective is to develop and implement systems with sufficiently good properties in order to satisfy stakeholders’ expectations and needs at a reasonable cost.

In order to operate as a structured and effective organisation, which develops and produces advanced products, it is necessary to implement effective working practices and processes which drive a value stream.

In order to operate effectively and to improve continuously, Saab has decided to base its operational management systems on an official standard so as to apply processes across the whole company in a structured manner. This standard is named ISO 15288 and it provides a framework for describing life cycles.

Background

Systems engineering is a relatively young area of engineering. The first time term was mentioned as part of the “Manhattan project” and with the expansion of the telecoms system in the USA during the 1940s.

During the 2nd half of the 20th century, systems engineering was mainly used within the aerospace and defence sectors, however now it is also widely applied in the automotive, biotechnology, transport and energy sectors.

Recommended reading

The author recommends the following texts that relate to this story: In chapter Keeping unique development skills under the heading Developing the world’s best control system, under the heading Agile methods in software development and under the heading System integration – unique expertise.

The text refers to the highlighted areas in the journey of change in the aircraft industry

Summary

Over time, the complexity of technical systems implemented in society as a whole and in companies in particular has increased. The need for quality and functionality has also increased in all the systems used in companies and society. This means that the number of properties to be considered and managed by each system has grown. As a consequence, the number of engineering disciplines required to contribute to the development of complex systems has increased.

From a technical perspective, the greatest challenge when developing the Gripen A/B was to create the basic platform, integrate all of the different systems and ensure that the aircraft was a stable flying platform.

When development on the Gripen C/D started in the middle of the 1990s, the complexity of the product had increased considerably when compared to the first version, the Gripen A. With the new versions, the focus had changed towards export and becoming a product which could be used in international operations – something which involved a completely new set of requirements.

For the Gripen E, we combined and further developed its strengths and the previous working procedure based on the experience from the development work on the earlier Gripen variants. Thanks to the improved modelling capabilities, it was now possible to come up with a design solution and to simulate large parts of the system long before they were built.

Description of the contents

  • During the 2nd half of the 20th century, systems engineering was mainly used within the aerospace and defence sectors, however now it is also widely applied in the automotive, biotechnology, transport and energy sectors.
  • Systems Engineering use a well-defined terminology to describe a systems and the process to develop, operate/maintain and finally retire it.
  • Systems Engineering has been applied in all major projects at Saab since the 1980s. How was applied has changed depending on the prevailing trends at the time.
  • SAAB has persistently worked towards increasing the understanding and competence within Systems Engineering. This has resulted in considerable improvements in the organisations capabilities, in particular the system integration capability.
  • Computer based support tools are still quite immature. The next step for better tool support will be to introduce model management support for multiple alternative system configurations.

Background to Systems Engineering

Even back in ancient civilisations, engineers and their predecessors created products and systems to satisfy the needs of individuals and society. An early example is the highly-developed transport system during the Roman period which crossed both land and sea. Good roads and organised Mansiones – Way stations – providing repair services and rested horses ensured fast, cost-effective and safe transport across land. The same can be said for the highly-developed harbours and the supporting infrastructure.

Systems engineering is a relatively new area of engineering. The first time it was referred to was as part of the “Manhattan project” and with the expansion of the telecoms system in the USA during the 1940s. During the 2nd half of the 20th century, systems engineering was mainly used within the aerospace and defence sectors, however now it is also widely applied in the automotive, biotechnology, transport and energy sectors.

The objective is to develop and implement systems with sufficiently good properties in order to satisfy stakeholders’ expectations and needs at a reasonable cost. Properties can be static such as for example weight, durability, density or bandwidth, or can be dynamic such as behaviour, current capacity, etc.

Complexity

Over time, the complexity of technical systems implemented in society as a whole and in companies in particular has increased. The need for quality and functionality has also increased in all systems used in companies and society. This means that the number of properties to be managed in a system has also increased. As a consequence, the number of engineering disciplines required to contribute to the development of complex systems has increased.

In order to develop a modern fighter aircraft system, such as the Gripen system, contributions are at a very minimum required from engineers with competencies in mechanics, aeronautics, electronics, operation and maintenance and software. The result is a large organisation with employees with different understandings of which system properties are important and what the optimal balance between them should be.

Systems engineering as an engineering domain

Systems engineering has emerged as the engineering domain for establishing and communicating an organisational consensus regarding the definition of the desired properties of the system from an operational and technical perspective in a structured manner.

The following table illustrates some of the system properties that must be taken into account when developing fighter aircraft. It is important to bear in mind that for each property, people with adequate education and experience to handle that characteristic are required to contribute in the development process.


The following is a list of possible system properties which must be taken into account when developing fighter aircraft.   

  • Radar cross-section
  • Service life
  • Fuel capacity
  • Weight
  • Environmental impact
  • Range
  • Supportability
  • Development cost
  • Survivability
  • Flight envelope
  • Operational cost
  • Availability
  • Safety
  • Centre of gravity
  • Fuel consumption
  • Maintenance interval

Basic Concept for Systems Engineering

Systems Engineering use a well-defined terminology to describe a systems and the process to develop, operate/maintain and finally dispose it. The terms used in the text below are based on information from the standard ISO 15288, 2008 “System life cycle processes”.

All systems have a life cycle. Life cycle models are used to describe simply which development or operational stage a system is at. In addition, the life-cycle model describes the focus within the value streams created when developing, operating/maintaining and disposing systems and products.

The image shows the life-cycle model used at Saab which involves six different phases.

The life cycle model

The life cycle model is divided into six different phases. Each phase involves a value refinement of the system or product. It is also worth noting that the last phase in the lifecycle, which involves the disposal or scrapping of a system, is also a form of recovering value. This is where certain components in the system or product can be re-used and enter a new supply chain.

Phases in the life cycle model

Initial studies: I denna fas genomförs inledande studier med syfte att utreda en eller flera aspekter av ett system. Denna fas används vid tidiga utredningar kring nya flygsystem eller vid tidiga studier av nya förmågor för existerande system. Fasen avslutas normalt med en rapport som summerar utkomsten av arbetet som genomförts.

Concept: Under konceptfasen formaliseras utvecklingsaktiviteterna med syfte att definiera ett koncept med tillräckligt goda egenskaper för att initiera fullskalig utveckling. Fokus under fasen ligger primärt på identifiering av intressenternas krav, analys av tekniska krav och arkitektur för systemet under utveckling.

Under konceptfasen utvärderas ett flertal olika koncept innan något väljs för vidare utveckling. För att kunna genomföra val av koncept måste även icke funktionella egenskaper utvärderas som systemsäkerhet, underhållsbarhet, utbyggbarhet och informationssäkerhet för olika systemkoncept.

Vid utvecklingen a Gripen-systemet används konceptfasen både vid definitionen av ett nytt flygplan, till exempelvis Gripen E men också för varje nytt ”förmågepaket” som ska integreras i systemet.

Development: Utvecklingsfasen innebär att den i konceptfasen valda systemlösningen realiseras och kvalitetssäkras. Det innebär att alla identifierade systemegenskaper och systemkrav verifieras. Dessutom valideras den realiserade systemlösningen i sin operativa miljö.

Production: in the production phase series production of the solution realised in the development phase is performed. Series production may requires the realisation of a complex production system.

Operation and maintenance: The operation and maintenance phase consists of all of the activities for securing the operation and maintenance of the realised system. This includes ensuring that the operation and maintenance organisation maintains and develops its capabilities.

Disposal: during the disposal phase, a system is taken out of operation and its components disposed of in an environmentally-friendly manner, meaning that the material used in it is recycled.

Processes

In order to operate a structured and effective company which develops and produces advanced products, it is necessary to implement effective working practices and processes which drive a value stream. In order to operate effectively and to drive constant development, Saab has decided to base its systems on the standard ISO.

This standard defines the processes and the accompanying terminology. It also describes the support processes involved in managing and improving life cycle processes used within a company or project.

The standard groups the processes into four different areas depending on their content.

  1. Agreement processes: consists of groups of company or interface processes for an organisation in order to interact with clients and suppliers in a structured manner.
  2. Project processes: describes how work on a project should be carried out. These processes describe how to organise the work on a project, how monitoring should be carried out, how the result should be evaluated and how information and configuration management is performed.
  3. Technical processes: this section groups together the different processes involved in managing the technical development of a system. This ranges from the identification of requirements from those involved up to the verification, validation, operation, maintenance and finally scrapping of the system.
  4. Organisational project enabling processes: this area covers the processes required to manage an entire company.

Saab has tailored the standard to meet the needs of the company. The purpose of the processes within Saab is to take advantage of market opportunities and to satisfy customer and other stakeholder requirements and expectations on products and services. The way to do this is to make effective use of the resources and skills which can already be found within the company.

Saab has also interpreted how the technical processes should be used throughout the life cycle. The processes run in parallel, and they overlap between several different life cycle phases.

The figure shows Saab’s process map of the technical processes over the whole product life cycle.

System structure

Subsystems and their properties are identified for the System of Interest. This is one of the basic concepts in Systems Engineering. The underlying idea is to split up complex systems into smaller, more manageable subsystems. The subsystems are then developed independently, then integrated into one whole which has the desired properties, i.e. fulfils the requirements set.

In the case of the Gripen, this involved splitting the aircraft into a number of subsystems such as the communication system, fuselage, weapons integration and decision support.

It is important to consider not only the subsystems of the System of Interest, but also the support systems required to realise, produce, maintain and finally dispose the System of Interest.

The development system is all those tools and methods used to develop the system the System of Interest. This includes MBD (model-based definition) for structural engineering and MBSE (model-based systems engineering) for systems development.

In order for development work to be effective, the development system needs to be as mature already at the beginning of the development phase.

The verification system covers the system elements required to verify and validate the system. This includes rigs, simulators, and test aircraft.

In the case of the Gripen E, this involved both software-based and hardware in the loop rigs.

The training system comprises system elements for educating end-users on how to use the System of Interest. This involves support for both the pilot and maintenance personnel. The training system comprises training materials and both pilot and maintenance manuals. The training system can also be found in the form of simulators such as for example the Virtual Maintenance Training for the Gripen C/D.

The production system comprises all the systems and production equipment in order to produce the System of Interest with acceptable quality.

The maintenance system includes tools, methods and personnel for field and workshop maintenance. This involves spare parts, diagnosis system, repair materials along with the applicable work instructions and information systems in order to maintain the Systems of Interests’ operational capacity.

The disposal system consists of the instructions and support components for dismantling the Systems of Interest in a safe manner and the recycling or scrapping of components in an environmentally-friendly and economically-viable way.

All of the aforementioned support systems generally also include the personnel required to operate the respective system.

The figure shows the associations between the end user system and the support system.

Developing the right system

During the entire concept and development phase, it is especially important to ensure close cooperation with the customer and the end-user. In Sweden is it the Swedish Defence Materiel Administration (FMV) and Swedish Armed Forces.

The greatest challenge when developing complex systems is that it is necessary to make overarching architecture decisions early on in the development process – at a point when the knowledge about the not yet realised system is limited.

The strategy to avoid this dilemma adopted at SAAB is to apply a Model Based Systems Engineering approach. Models are developed and refined throughout the process in cooperation with customers and subcontractors.

Usage of different types of simulators are key to day-to-day engineering. By continually and systematically developing models of the subsystems, integrating them to represent the complete system, it is possible to get insight into the impact of different solutions on the overall system early on in the concept work. Apart from supporting the development of the aircraft and weapon system these models are also used to creating training and support simulators for use by the customer organisations.

An additional challenge when developing complex products is that change is very expensive when there is adequate knowledge of the positive and negative aspects of the selected system solution.

One key Systems Engineering objective is to accelerate knowledge acquisition early through well-constructed concept phases. It is also important to review any solutions put forward to ensure that the best possible solution is chosen.

The figure illustrates how commitment to actual technology, performance and cost is made in a situation with limited knowledge of the system under development. Moreover, the cost for decisions made is not incurred until later in the lifecycle. On top of that, it is very expensive to change and correct the system by the time consequences of poor design decisions are evident.

Technical reviews is another means to ensure the quality of and to coordinate the development work. This is done by both internal and external stakeholders being given the opportunity to improve the suggested system solution prior to it being realised and at the same time to gain an insight and common knowledge on the solution. Thanks to the technical review, it is possible to track how a system matures, both with regard to the content and the quality.

Applications of Systems Engineering

Systems engineering has been applied in all major projects at Saab since the 1980s. How it is applied has changed depending on the prevailing ideas at the time within systems engineering community. Other factors have also played a role, including challenges which the company has faced which have been particularly complex. The following section will describe the application of systems engineering to the development work from the Gripen A/B to the Gripen E.

Gripen A/B

From a technical perspective, the greatest challenge when developing the Gripen A/B was to create the basic platform, integrate all of the vehicle systems and ensure that the aircraft was a stable flying platform.

Apart from the fact that all of the technical solutions were completely new, there were also large technical challenges due to the materials used (composite) and the necessity of creating a whole new digital flight control system for an unstable aircraft.

The development of the Gripen A (single-seater version) mainly took place before the world had become digital, so hand-written documents and drawings which were a normal part of the technical documentation creating un the development work. The use of CAD for mechanical and electrical design was not introduced until the development stage of the Gripen B (twin-seater version). Consequently equipment installation and interconnectivity was validated using traditional means – using wooden models of the aircraft.

Early development work on the Gripen A/B was performed in relatively small development teams and the system was, relatively speaking, less complex than later versions of the Gripen. Consequently, it was, relatively speaking, easy to achieve a good overview of the entire system, meaning that communication between the different system developers was much simpler compared to later Gripen versions.

A hardware in the loop simulator, “Syrig” was developed for system wide verification and validation. Additionally there was a small number of less advanced rigs and simulators available to support development work. Traditional basic aircraft rigs were developed in order to verify basic aircraft vehicle systems such as the fuel, air and hydraulic systems.

In summary, we could say that the development methodology applied to the Gripen A had a focus on described the system’s architecture and design, but the capture and management of requirements was not so strong.

Gripen C/D

When the Gripen C/D was developed in the middle of the 1990s, the complexity of the product had increased considerably when compared to the first version, the Gripen A.

The focus had shifted, and the Gripen was to be exported and become a product which could be used in international coalitions. This resulted in an entirely different set of requirements. In addition, developments in technology meant that many systems either had to be upgraded or completely replaced. A unique Swedish solution which was completely adapted to Swedish needs had to be totally overhauled to turn it into a system ready for the export market.

A joint agreement with BAE Systems was set up for export sales. The focus of this was to use an internationally-accepted methodology.

Compared with the original development of the Gripen A/B, the basic aircraft had already been worked out and was well-known. The challenge now would be to increase the aircraft’s functional and operational capabilities. The avionics system was extensively updated and more powerful computers were introduced.

Within Systems engineering, the main focus between the late 1990s and the mid-2000s was on requirement management and process definition methodology. These areas were considered key for effective system development. In addition, the first versions of MBSE tools were available on the market. Characteristics of these MBSE tools were that they provided a modelling capability and a limited simulation and code generation capabilities. Due to quality concerns, the code generated was, however, only used in simulators.

Comprehensive investment was made in researching and introducing system modelling. To name just a few examples, xmath/Systembuild was acquired for signal/control system-oriented modelling and Boeing’s Easy5 was acquired for hydraulic modelling. Some of the main characteristics of these systems were that they gave the organisation the capability of carrying out simulations of activities within the separate engineering discipline frameworks and for stand-alone systems.

A modern requirement management methodology was introduced and the Telelogic DOORS tool was acquired to support the methodology. In addition, investments were made in research into the storage of information on systems engineering regardless of the tool used. Saab was one of the drivers in the creation of the AP-233 data exchange standard which can be found within the framework of the ISO 10303 family. Unlike the development of the Gripen A/B, all development systems were now entirely computerised.

The general understanding at the time was that the formalisation of development processes should lead to considerable improvements in quality and productivity. This was adopted at Saab and comprehensive work was carried out with a focus on documenting processes. The work at Saab was carried out generally the same approach and results as for the sector as a whole.

The main focus was to define sequential streams. Instead of integrating all of the activities into a small cohesive group of processes, a set of domain-specific processes was created. The result was a comparatively large number of well-defined processes but with inadequate inter process integration. At the same time, knowledge was limited on how the processes could really be made to be executed.

Additionally, it was not entirely simple to define the content required to describe the engineering work needed to develop such a complex system.

The result was a comparatively static process in which requirement management was prioritised over the description of the architecture and design, mainly due to the fact that the DOORS tool proved to be the only tool that could really be used on a large scale and across the entire organisation.

Gripen E

The challenges when developing the Gripen E are similar to those when developing the Gripen A/B and C/D in both quality and quantity. Many of the basic vehicle systems had to be modified or completely replaced. At the same time, the entire avionics architecture was being replaced by more powerful computers and new sensors. Just like when developing the Gripen A, there were components which could be considered mature and completely integrated, however there was also the issue of the desired system behaviour and characteristics which could only be seen once the system had been completed.

The system development processes which is applied for the Gripen are those described at the start of this chapter. The process definition puts emphasis on both the identification of requirements and how to document the design in an effective manner. In order to be able to do this, it is important to integrate all of the input from the different engineering domains in the development process. This means that all processes must be active and coordinated during the development work.

The development teams are already large from the very beginning and thus effective communication of the selected design solution is of high priority.

Systems engineering training based on INCOSE’s Systems Engineering handbook was carried out with the aim of certifying the participants as Certified Systems Engineering Professionals (CSEP) has been introduced to improve Systems Engineering competencies.

Before the development of the Gripen E a whole series of new development systems were introduced, including the latest generation of construction and modelling tools. Examples of thiese are Dassault Catia V5 with its support tools, Modelica-based tool Dymola, Mathworks Matlab/Simulink, Onefact Bridgepoint and IBM Rhapsody.

The simulation capabilities provided by these tools are many times more powerful compared to the tools which were used when developing the Gripen C/D. In addition, the possibilities of integrating models developed in the different tools has increased considerably. For example, it is now possible to simulate physical models of subsystems in the aircraft (modelled in Dymola) in conjunction with models from the control system (modelled in Simulink). This makes it possible to achieve a good understanding of the system’s characteristics very early on, which in turn makes it simple to optimise the selected design solution.

In addition, the code generators in the tools and the associated methodology are now mature enough to generate code for execution in an aircraft.

In addition to enhanced modelling tools, new simulator systems have been developed. They can be used to increase the possibility of integrating and verifying as much as possible in the system early on in the development work. These process can be carried out before being integrated into the aircraft.

Simulators, completely implemented in software such as “MySim” have also been developed. This simulator gives each individual engineer the opportunity to simulate the entire system on his workstation. Compared to the Gripen A/B development, this is an enormous improvement in capability. At that time there was just a very limited number of testing stations which could be used to investigate the entire integrated system.

Reflections

Long-term, persistent work towards increasing understanding and competence within systems engineering has resulted in considerable improvements in capabilities. In the case of Saab, this is particularly important for the technical area we refer to as ‘integration’. Individual accountability in the network between the different co-workers is a guarantee for improved organisational capabilities within Saab more than any documented process descriptions.

In order to develop any kind of basic capabilities within systems engineering, it is essential to have additional initiatives for skills transfer after the completed product development project and between ongoing product development Project. The exchange of experiences between different technical disciplines should also be developed even more than driving technical development. The reason behind this is that it is important to make the most of technical developments within an area as they can often have a great influence on other technical spheres.

The following is a very short comparison of the 3 different generations of the Gripen:

Gripen A/B

Development of the Gripen A involved some very large technical challenges. The systems engineering was handled by relatively small group of engineers. Communication paths were short and the organisation doing the development work had a good understanding of the system as a whole. Documentation of the system focused mainly on the design solution. The group working on the project was relatively small, so formal development process was of secondary importance.

Gripen C/D

By the time the Gripen C/D was under development, the complexity and size of the team working on it had grown so much that the development need to be formalised and organised according to what was considered state-of-the-art when the project began.

The result was a methodology based mainly on managing the requirements at the expense of the architecture and design. The development process had a strictly sequential working procedure. The introduction of the first generation of tool from model-based working resulted in a limited possibility of getting feedback on a solution before its implementation and integration.

Gripen E

For the Gripen E, we combined and further developed its strengths and the previous working procedure based on the experience from the development work on the earlier Gripen variants.

Thanks to the improved modelling capabilities, it was now possible to come up with a design solution and to simulate large parts of the system long before they were built. At the same time, it involved taking advantage of the earlier experience working with requirements in an organised manner. Requirement management was used to identify early on the system properties to be verified.

The fact that the development team is so large means that working with processes is essential. In order to ensure the required flexibility and rationality when working, it is possible to modify these processes. This is essential for being able to work in parallel with different aspects of the development work.

Systems engineering in the future

Nowadays, large parts of the Gripen E system can be modelled and simulated with high accuracy in a completely virtual environment. The disadvantage of the current development environment is that it is dimensioned to handle models one system configuration at a time.

The next step for improved tool support will be to introduce the management of several alternative configurations for different models and so simplify the evaluation of different concurrent alternatives, not least to simplify the parallel development of complex systems. Similarly, the possibility of integrating models from different engineering domains is also on the increase.

A prerequisite for this type of development is that characteristics identified in the model can be interpreted automatically by other models. This requires further development and more widespread acceptance of open standards such as FMI (functional mock-up interface). This development will make it possible to get feedback faster within the development of separate subsystems, but may also provide quicker answers regarding how modifications in the subsystem can have an effect on the capability of the entire system.

Integration and simulation capabilities will result in greater confidence in the system before it is carried out, and feedback ensuring confidence in the models created is central for effective development. Consequently, it is not sufficient just to connect models together but they must also undergo continuous improvement by feeding in measurements from testing on completed components and subsystems.

This feedback remains a manual process. In order to automate it, it will be necessary to come to an agreement on how machines should interpret the information generated from different development systems. Emerging standards such as OSLC (Open Services for Life cycle Collaboration) are looking promising.

The systems we have today are already so complicated that it requires large, costly efforts to verify using simulation and traditional verification methods. For a long time, it has been criticised that formal methods are the only practical way of ensuring cost-effective verification.

After a long development process, formal methods are now becoming so capable that they can be used for complex industrial systems. Broad industrial implementation will require both comprehensive training of users and also further simplification of tools for implementing these formal methods so that they are even easier to use.

The author´s reflections