System integration – unique expertise

Background

Saab has been working with integration capabilities since the first military fighter aircraft appeared after the Second World War. The main change since then is that the complexity of these aircraft has grown dramatically.

Recommended reading

The author recommends the following texts that relate to this story: In chapter Creating value for customers under the heading Development of Technology Demonstrators in chapter Having a low life cycle cost under the heading Systems Engineering and in chapter Keeping unique development skills under the heading Designing the world’s best control system.

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

What are integration capabilities? We will look at several different answers to this question, however all the answers are in some way interlinked.

For integration capabilities to be ‘worth something’, it is essential that they are communicated and understood by everyone developing the product. Communication between everyone involved in product development is key. It is important to communicate which architectures and design decisions are made and which interfaces are defined.

The interfaces are particularly relevant; it is essential to specify all of the different types of interface, e.g. mechanical, electrical, system/technical, frequencies, signals, protocols, etc., and which type of testing, system testing and mechanical testing, etc., is required.

Well-functioning integration work forms an entire subset of the total development process for a system or product.

Saab’s operational management system has a number of processes describing how to ensure and approve the designs being developed and supplied.

When the Airframe (structural engineering) technology area started working on developing the Gripen E in 2008, there was not a sufficient number of experienced engineers available. This meant that for several years the company had to develop both smart working procedures and at the same time build up the necessary skills.

The way they did this was with extremely well-structured capacity development. In this work, systematic capacity development was carried out in all of the technical areas within Airframe. After several years it could be both seen and measured that the overall capabilities in all of Airframe had increased dramatically.

Description of the contents

• A short description of systems integration in the development work will be given with the different aspects in integration capabilities and what is required to ensure success in systems integration in large systems and product development project.
• Integration work in the development process is summarised and described with the principles and main working procedure for integration in systems and product development.
• Effective development within the Airframe technical area illustrates how the journey can progress when how to face the integration of different types of systems is in focus. The work refers to improvements in the process, method and working procedure for the Airframe segment of the Gripen E development team.

What are integration capabilities? We will look at several different answers to this question, however all the answers are in some way related. To understand the process, we will need to answer the following questions:

1. Is there an accurate set of requirements in order to ensure that the customer can get the required operational utility?
2. Is it possible to achieve a solution within a defined time and within an economic framework which is consistent with the operational utility?
3. Can the system be developed further?
4. And do we have a maintenance solution that can fulfil the requirements for operational capacity?
5. Have assessments also been carried out from a holistic perspective and has the system’s life cycle cost in taken into account?

Can the answer to the aforementioned question be that integration capacity is the skill in making complicated systems work together?

To specify all of the above, first of all we must define what is meant by integration capacity. Integration capacity is a skill which consists of several parts:

1. Integration capacity is understanding what makes a good system solution according to the product’s characteristics. This involves understanding systems as a whole, i.e. the capacity of understanding and converting the customer’s operational requirements into an effective product. This requires conceptual understanding and knowledge of operational analysis.
2. Integration capacity is converting comprehensive capabilities into a technical solution. This requires architecture and design knowledge in order to create a product which should preferably be modular and flexible in design. This means that the product can be developed in a flexible way and different parts can be exchanged as technology continues to develop or as adjustments are required.
3. Integration capacity is the development and manufacture of a product. This requires experience and knowledge of systems engineering. It also involves understanding how to solve engineering-related problems in order to make multiple systems work together. The required knowledge for solving complex compound problems is required.

To put it simply, one might say that integration capacity is the capability of seeing systems as a whole and understanding how to create that whole from separate parts.

Integration capacity requires communication

For integration capabilities to be at all useful, it is essential that they are communicated and understood by everyone developing the product. Communication between everyone involved in product development is key. It is important to communicate which architectures and design decisions are made and which interfaces are defined. It is particularly important to ensure good communication regarding interfaces: it is essential to specify all of the different types of interface, e.g. mechanical, electrical, system/technical, frequencies, signals, protocols, etc., and which type of testing, system testing and mechanical testing, etc., is required.

In order to ensure that the design is balanced, it is essential that the system requirements be well-defined and have an accepted objective. Design budgets and the interface for the overall design must be fixed. Design budgets are required for the availability, system safety, operational capacity, weight/size and power/cooling.

As a complicated product such as the Gripen encompasses so many different components, subsystems, systems and apparatus which all need to work together, those working on it must have solid training and years of experience in order to lead the integration work.

In order to be able to take on responsibility for such a product, it is essential to understand how the product is constructed at all levels.

Integration capacity requires long-term development of expertise

Integration capacity is something which is built up over time as experienced engineers develop an understanding of the whole system which is then passed on to the different individuals responsible for the separate levels as seen from a product architecture point of view. In the case of the Gripen there was a weapons group structure which was responsible for defining clearly the concept as a whole including the different parts and how they should work together. In order to maintain high levels of integration capacity, it is important to have a relatively limited number of people who can work together long-term.

The Swedish philosophy of developing products is characterised by the belief in achieving innovative solutions offering effective results with limited means and few resources. This requires the experience gathered in the different technical areas and technical disciplines to be maintained over time in order to keep the capabilities up-to-date. If there is too long a period of time between new product developments, this capacity is at risk of being lost.

How to maintain integration capacity over time

One of the factors behind Saab supporting technology demonstrators is to maintain skills within all of the technical areas, not least in order to maintain our unique integration capacity. The implementation of technology demonstrators gives us the opportunity to train and test new people in solving advanced technical challenges with the aim of maintaining and developing technical skills and integration capacity. An excellent example of this is the avionics demo made as part of the framework for the Gripen Demo technology demonstrator. This involved the development of a new architecture which would be both modern yet could also be extended over the coming decades.

Those involved in this project had knowledge about the entire Gripen product and its use, as well as ideas and knowledge about possible future new products.

Integration capacity requires all of the technical areas to have broad technical knowledge and to understand how to solve problems and use technology. This is why it is essential that the integration capacity technical discipline has such a status and mandate so as to steer and drive long-term training and development within the technical discipline. This requires having sufficient resources in order to continue to provide the required methodology support over time in all of the technical areas and for all product development projects.

Each product project and each product owner shall, of course, be responsible for their product but in order for the integration capacity and skills around this to be maintained long-term, it is essential that integration capacity has the required mandate and importance.

Integration requires successive development

Integration involves working successively on developments. It is an incremental process, where the customers can test out different variants of solutions to see if they fit their operational requirements. The best way of carrying out this work is often with a model-based working procedure. The next step is the concept work, preliminary project, development, etc.

In certain cases it can also be wise to start the work with a round table meeting and drawing-board simulation. Normally, some sort of simulator facility is used to describe and test different operational capacity scenarios for a customer.

Concept work is risk-minimisation work and comprises three sub-steps, namely needs analysis, concept exploration and concept definition.

The life cycle stages are recursive, that is, they describe a working procedure that is repeated several times in a development project. The recursive flows are generally considered a hierarchic breakdown of the system into subsystem levels, with concepts created for each node of each leg of the breakdown.

The recursive flows can even be dynamic, with concept maturity successively developing until sufficient maturity for a product definition is reached. This can happen as a result of functional growth. The respective functions are added together successively to the system and to the interactive system. Was the concept is mature, we move on to the system development phase which follows the same principles that has a higher technical maturity and is the phase during which the actual product is created.

The concept is fundamental for integration work.

Working on developing the concept is fundamental for integration work. The operational conditions proposed via needs analysis, scenario descriptions and tactical/technical mission descriptions, Concept of Operations (CONOPS), are compiled in an Operative Concept Description (OCD). The OCD containing the scenarios and product concept must be developed in symbiosis with the development of the design solution.

The analysis and establishment of tactical/technical interaction requires an incremental working procedure. It is then a question of focusing on breaking down and assigning the characteristics, requirements and design budgets within the different systems. This is followed by maturity development according to which the system is developed and verified. The result of this is information on the expected time, risk, cost and technical content. The continued development work consists of continual testing, reviewing and demonstrating.

In principle, requirements validation can take place when the result from a development step is checked off against a CONOPS. Depending on the results of this testing, the result is corrected or the incremental development work is continued. There is generally also a kind of project evaluation group which decides whether the maturity of the solution is correct with respect to the project integration plan.

Integration work requires technical projects running in parallel

One way to describe integration work is the importance of running many different technical projects which need to run in parallel and the results of which must function as a whole.

In order to achieve integration capacity, it is important to build up methods and working procedures which describe how to construct a system and to train, lead and support the technical work. It must be possible to simulate the possible choices before starting with development work. Part of development work involves the comprehensive testing and reviewing in order to verify the maturity of functions and systems. Continual feedback with the customer is required from the very beginning to ensure that the product will be approved. Every single test and review must verify that the defined requirements are being met.

Integration requires steering with the participation of the integration management. It is important to test the conceptual model a number of times during the project development stage in order to ensure that the system corresponds to the original requirement specifications (OCD).

Working with integration requires experience and broad skills. The following points are particularly necessary to ensure effective integration work.

1. The leadership must ensure common principles to keep the resources in balance.
2. Participants must have the right knowledge, respect for knowhow and curiosity to learn new things.
3. There needs to be a good network in which communication is characterised by a lack of personal prestige and where the participants are free to say that they require more knowledge on the subject.
4. It must be possible to discard ideas which are not working and try different sequences.
5. Everyone must be working in parallel and according to the defined methods and processes.
6. The must be a special focus on questions regarding airworthiness, verification and validation and for creating well-structured documentation.

This chapter summarises the principles and overall working procedure for integration in system and product development.

Saab’s operational management system has a number of processes describing how to ensure and approve the designs being developed and supplied.

The figure shows the area of Saab’s operational management system which deals with technical development.

Development work involves a number of steps to testing and validating a d manage and plan this successive development work, it is essential to have clear, well-functioning integration management on several different levels in the product development project. Prerequisites for how the development work will continue must be specified in the very early stages of the system development work.

Development work is incremental, and consists of gradual development and closer integration of systems. It also involves comprehensive testing and verification of systems and functions.

Rational integration capacity requires short lead times

Developing large systems is a very complex process. A large number of interfaces need to be taken into account and the systems can show different behaviours depending on how they have been developed. It is important to have a sound break-down/division of the system. Large systems development projects can undergo changes which mean that the system needs to change its character when integrated with other systems.

In order to increase the quality and technical maturity in the system, and therefore save time, it is a good idea to develop systems incrementally. Once sufficiently good results have been achieved, the entire system should be tested, possible non-compliances and errors should be corrected and the entire process should be repeated 3 – 4 times.

This working procedure generally achieves results which are as complete as possible within a short time frame.

Under normal circumstances, the maturity of a system will develop according to the graph shown on the left below. By employing the working procedure described above, it is possible for the system to develop and grow in a much shorter time such a shown in the graph on the right below.

Integration capacity: creating a whole and balancing the design

Clear concept work is required for setting prerequisites in order to achieve good integration capacity.

This means having carried out early validation of both the requirements and the design. The aim of this is to create a whole system and to balance the design. It is also important to ensure a comprehensive and coherent design to ensure unity in the system thanks to well-functioning integration of all of the subsystems. Integration requires having control over economic budgets in order to achieve cost-effective solutions. It also means keeping tabs on the technical budgets defining how much weight, electricity use, memory capacity, cooling, etc. engineers have at their disposal so that the whole system will work together.

Basic skills such as a sound knowledge of systems engineering are essential. In order for that work to proceed smoothly, it requires leaders who are completely familiar with systems development as a whole and with model-based systems development, including testing and verification in particular so that the integration is a success at all levels.

Roles in integration work

The leadership roles involved in the system development project can be divided into 3 groups:

1. Project leaders running the projects are ultimately responsible for time, technology and costs.
2. Design managers running the technical construction work are responsible for ensuring the requirements are complied with and for the product declarations.
3. Integration managers running and planning the integration work and producing the integration plans on a general level.

In order to steer the integration work on a practical level, different obligations are set for the weapons groups and development teams. This involves defining the dependencies between the different functions and systems.

The figure shows how integration issues are handled in principle.

The strategic development plan for system development project describes basically the integration involved for an aircraft. They can be summarised as follows:

• Aeronautical & systems integration - weapon system.
• Systems integration - systems, apparatus, aerodata, technical support systems for the aircraft.
• Installation kit design - installation descriptions.
• Maintenance - weapons, “Ground Systems Equipment” publications.
• Test, verification & validation - controls to ensure maturity in the technology, quality, function and flight safety.

In order to be able to track the development work in detail, all the activities are divided into milestones of different types and different areas. This makes it possible to track the progress for each defined activity in a project plan and therefore always be in control when steering and leading the project.

Principles within systems development

In principle, systems development work can be described according to different phases and activities.

A central part of the work in systems integration is planning which configurations should be included in a certain edition delivery and which constitute the final results of the development project delivered to the customer.

To do this, one single unique image of the content in the edition is created by the project participants, programme leader, testing company and chief engineer.

This common image specifies the content, important milestones and working procedure. Follow-up happens at a later stage so that all of the stakeholders find out how the edition is developing and to ensure that all of those involved are agreed upon the content and the influence on other systems.

The following figure shows an extremely simplified representation of the procedure for general system work

Once the development work has achieved the results, the content for that edition is fixed (frozen). After further work on the development and integration, a decision is made on the maiden flight. The next step is to finish all of the work by checking that all of the approved modifications have been carried out and that the decision can be made stating that the work on the configuration is complete.

Development planning and integration work

Integration work is part in the value stream when developing a product or system. To get a clearer image of this, it is important to see which plans steer the development work and therefore the integration work. Generally there is always a plan at the highest level for the development work. This development plan is used to set the framework for the organisation as well as the commitment to the contract. This kind of plan is often updated on a quarterly basis or when necessary.

In order to keep the focus on upcoming and future activities, there is a planning window of 6 weeks in rolling planning. The planning comprises a general plan, review meetings, risk workshops, etc.

For each obligation there is a development strategy which is described at the highest level in the project. This involves the definition of the activities and different types of important milestone. In addition, it also defines which products and configurations are affected by the delivery. This agreement takes place at a weapon system level.

Weapon systems plans consist of the different development steps for the product which correspond to the obligations and customer orders included in the plan. The plan is devised as a whole – i.e. at a weapon system level – which defines the products included in the obligation.

A weapon system plan consists of two parts. The first part is the development stages on a general level for the entire weapon system. The second part involves the products included in the weapon system. If you ‘break down’ the weapons system plan, you come up with a technical framework.

This framework in the form of partial editions involves an increment directive which controls (content) what is important in each partial edition and which configurations are produced. It also includes a matrix with the integration schedule for the products affecting each partial edition.

The work with partial editions is developed incrementally with shorter development phases and at a regular predictable pace, as well as with clear conclusions to the work.

It is appropriate to carry out system development in different stages. The development work should be split into several increments which then form/make up the whole system. An increment is a functional development of a system, for example, which must be part of the delivery. It is a fully developed and verified version of the complete system, but with the limited capability.

The increment directive could be described as the systems and functions to be included on how the system will grow and become integrated. The main aim of the increment directive is to set the objectives for and the basic content of the increment and its partial editions. The content and definition in partial editions and deliveries is managed in the increment directive.

This also includes specifying the configuration for the integration schedule, in the work package and the production of certain change documents in the current development increment. The configuration in a specific configuration control tool are created based on the agreed deliveries.

This section illustrates how the journey can progress when how to face the integration of different types of systems is in focus. The work concerns making improvements in the process, method and working procedure within the Airframe technical area and deals with work on the Gripen E.

Gripen E is a more developed version of the other Gripen aircraft. New customer requirements have meant that approximately 95% of the aircraft fuselage and installations have had to be redesigned to have a lower weight, more room, more storage space for fuel, more sensors and a higher resistance to temperatures and pressures, etc.

The following description of work only covers the Airframe technical area. This technical area covers the weapon systems/function required for development with regard to construction, strength analysis and production engineering for the fuselage as well as the respective system installations (wall pipe, electricity, fuel, air and hydraulic installations). In addition, it also includes the production of loads on the aircraft, the weight on all apparatus and components in the aircraft as well as aeroelasticity and flutter in the Airframe technical area.

Prerequisites 2008

When work began in 2008, there was already a process for how the work was meant to be carried out. This process, called ADI (Airframe Design and Industrialization), was part of Saab’s operational management system.

At that time, the process was described in such a way that a great deal of interpretation of the process descriptions was required. The process described how to work so as to ensure compliance with the product requirements. It also described how the design should have been carried out. This was done in 3 main stages: a conceptual phase, a preliminary construction and then detailed construction.

The project to comply with the aforementioned customer requirements consisted of approximately 400 project members.

As the project was so large with so many different project members, it was extremely important that the activities in the development work could be managed with very controlled planning. It was also essential that the technical maturity of the project results run in parallel and that everyone was working incrementally in the development work so that this technical maturity was also verifiable.

Early on in the project, MBD (Model Based Definition) was selected for all of the work, meaning that the entire development was carried out without paper drawings.

The main aim behind this was to harmonise the data and to provide a technical baseline which was available to all project members involved. This working procedure meant that all of the data could be recycled through the whole stream and reduce the need for hand-overs to all stakeholders in the product data created as part of the project.

The scale of new developments had not been carried out by the generation of engineers that was available in 2008.

At that time, the Airframe technical area had a shortage of experienced engineers. The ADI process and review process in use at that time was developed for more experienced engineers and was not suitable for the large volume of work which needed to be done and reviewed.

The project concept phase took place between 2008 and 2009. Work was carried out in a traditional manner with studies covering the functional aims in close cooperation with our customer, the Swedish Defence Materiel Administration, FMV.

Within the organisation at that time there was not sufficient insight into the extent of the coming challenges, and the project did not have enough staff with experience.

When work was underway in the construction phase in order to create a preliminary construction, it became very clear that the knowledge regarding this new construction and cross-functional work was not sufficient among those who were working on the project at the time.

When reviewing the preliminary design for certain constructions, it became clear that the result did not have the required technical maturity. In addition, the review work was cumbersome and did not have the required quality. As a result, the product did not comply with the requirements and the necessary product data. It became clear that knowledge regarding the scope of the project, the content, the level of complexity and the requirements was inadequate and required reworking.

Experiences from the early phases of the project were as follows: the project had unequal levels of maturity, the review was inadequate and carried out too late, the level of training was too low and there was a lack of information within the project.

As a result, the technical management group of the project decided that a number of changes had to be carried out. These were as follows:

• Reviews must be carried out directly on the product data, not on presentations in conference rooms.
• Working procedures should be fixed within all of the different technical areas in order to achieve the correct technical maturity and results and that construction must proceed in parallel.
• The product requirements and their current maturity must be visible for all project members.
• Technical decisions must be made quickly and that these decisions must follow directly after review or monitoring. Decision support also needed to be strengthened.

Step 1 change management 2011-2014

The first step in the change management work was carried out between the years of 2011-2014.

The changes introduced can be summarised as follows:

1. Large parts of the review stage were carried out early on in the process by engineering managers. DMU review was started with a strictly-controlled agenda. The results were categorised in a scale red/yellow/green depending on the severity with regard to compliance with requirements. The project should focus on the red problems first.
2. Many of the requirements were formulated with filters in the CAD systems and became visual for all DRI models.
3. At the same time the technical maturity became clearer in instructions for review and training was carried out in ‘sound construction’. Tasks were structured and the necessary changes were described and distributed to the respective weapons groups for action.
4. The maturity of the product could be evaluated according to the status markings (colours as above) on the aircraft when logging into the CAD system.

The results of the change management work can be summarised as follows:

1. The aircraft with the status markings gave project participants clearer information on the technical maturity of the aircraft and the process involved in making it more mature from “red to yellow to green” was clear to follow and could be used by the whole Airframe department. The red, i.e. immature, areas were clear to see to all the project participants and everyone knew with the help of actions lists what still needed to be done for the aircraft to be sufficiently mature to be approved.
2. Clearer prioritisation was carried out. The red areas and respective actions were prioritised by appointing experienced engineers in a workgroup per area. This resulted in the closing of actions being completed much earlier: approximately 1,000 actions within the space of 6 months.
3. The review group, the technical management and the project management all report that there is a better understanding of the scope and content of the task.
4. The ‘sound construction’ with visualisation concept is introduced. Thanks to the DRI models, there is greater clarity and better understanding of how the products requirements can be fulfilled in the design.

The figure illustrates the points made in the text above

Step 2 change management 2015

Experiences from producing a test aircraft for the Gripen E continue to be developed as series adaptations for the Gripen T.

This work is carried out with the help of ‘review start-ups’ and monitoring, i.e. front-loading of the work. Scraab has also been introduced, as well as a day-to-day technical decision support for all technical managers. In addition, access to daily support from experienced engineers, MGA and CI is also provided.

We have also implemented and carry out incremental working procedures for each development phase. This working procedure has been standardised and collected in a procedural description. This involves working towards approved review in a so-called “FIA game”. The “FIA game” is based on a visual scheme with the maturity status at the moment which leads to a completed stage (PDR).

The concept phase begins with a concept study. This study and the steps making up the phase are meant to specify the requirements, budget and architecture and design principles required for the entire aircraft.

The preliminary design phase will specify the interfaces and the requirements and will result in a preliminary construction which is both robust and ready for further development. The detailed design phase concentrates on the details and setting the die mentions of the construction in accordance with the requirements and the agreed interfaces.

Analysis of the results indicates a development in capability

If we compare the situation in the Airframe technical area in 2012 and 2015, we can clearly see that capability development has been successful. The capabilities have increased dramatically thanks to comprehensive implementation and focusing on a model-based working procedure (MBD).

The table shows a comparison of the levels of maturity in the organisation.

The next stages in the journey of change

The aims of the future working procedure for the twin-seater version Gripen F involve specifying a clear baseline of all of the data in order to ensure that everyone is working towards the right data. In addition, the concept phase process will be made clearer with an FIA game towards CER and learning the lessons from what was explained above.

The next stages in the journey of change consist of the following:

• To ensure the quality and content of all of the product data so that everyone is working towards the same prerequisites.
• To clarify the process for the concept phase with an FIA game towards CER, i.e. a visual scheme displaying the current maturity status with the concluded steps (CER).
• A new working procedure for how to make decisions regarding and structure study work.
• Implementation of the “Structural technology” technical discipline’s work in the MBD stream.
• To implement methodologies and working procedures with the help of MBD to reduce weight in all constructions.

All in all, the aforementioned has resulted in a clearer information stream in the project and improved awareness of the current project status among participants. This has resulted in a product which has become more harmonised and quality-assured as work has progressed. The subjective opinion is that work has become much more effective. The colour-coded aircraft gives the project participants clearer information on the current technical maturity of the aircraft.

The process of making the aircraft more mature from red to yellow to green is clearly managed and applied across the entire Airframe technical area. The red, immature areas, are clear for all project participants and they know with the help of visualisation is an action lists what is required for it to become sufficiently mature to pass review.

Prioritisation has become clearer with the red areas and actions being given priority thanks to the appointment of skilled engineers in a working group per area. This resulted in the closing of actions being completed much earlier: approximately 1,000 actions within the space of 6 months.

We have achieved more harmonised terminology and targets thanks to ‘sound construction’ training. Within a year, daily technical decision support has been reduced to 4 decisions per week.

In order for these large changes to be successful, a number of prerequisites were required – most of which involved communication. They can be summarised as follows:

1. An experienced cross-functional management group with one single goal. In this case, approximately 10 people with good continuity. Six of the ten have been with us throughout the whole journey.
2. Conscious, long-term focus on methodology and tool support from the line organisation.
3. Good cooperation between project – line – technical management.
4. A climate in which ‘knowledge’ is inherited from one project to the next; Neuron – B787/Airbus project – Gripen E – TX.