This section gives an overview of the questions which need to be understood when carrying out complex system development work involving the development of advanced products. To get large complex systems to function in the desired way involves understanding how development work needs to be carried out and how to integrate all of the different systems.
In order to be able to stick to deadlines during development work, it is essential to be able to control many different development teams.
Each system needs to be tested separately to ensure that they function correctly and that they have the specified capabilities. When the systems are then being tested together, there are many interdependencies which can affect each individual system.
This is why the integration work must be done so as to ensure a good overview of how the functions operate within the subsystems and system as a whole in a structured manner. Technical maturity of a system grows successively via incremental development.
This means that an entire subsystem can also develop increased maturity as the development work progresses. This is why it is essential that the development work can be managed in such a way so as to ensure that all of the development teams are working in coordination with the technical maturity of the systems and in order to stick to the schedule.
In the example described to the end of this chapter, we will explain why it is important for all of the development teams to work in a synchronised manner.
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.
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.
This chapter gives a short description of different aspects in integration capabilities and what is required to ensure success in systems integration in large systems and product development project.
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:
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:
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.
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 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.
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 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.
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.
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.
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.
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.
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.
The leadership roles involved in the system development project can be divided into 3 groups:
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:
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.
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.
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.
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:
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:
The results of the change management work can be summarised as follows:
The figure illustrates the points made in the text above
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.
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 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:
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: