Key Challenges in Software Application Complexity ... - Science Direct

Available online at www.sciencedirect.com

ScienceDirect Procedia CIRP 37 (2015) 24 – 29

CIRPe 2015 - Understanding the life cycle implications of manufacturing

Key Challenges in Software Application Complexity and Obsolescence Management within Aerospace Industry Raúl González Muñoza , Essam Shehaba*, Martin Weinitzkeb, Rachel Bencec, Chris Fowlerc, Stephen Tothillc, Paul Baguleya a

Department of Manufacturing, School of Aerspace, Transport and Manufacturing, Cranfield University, Cranfield, Bedfordshire, MK43 0AL, United Kingdom b Airbus Operations, Hamburg, 21129, Germany c Airbus Operations, Filton-Bristol, BS99 7AR, United Kingdom

* Corresponding author. Tel.: +44 79 50554 084. E-mail address: [email protected]

Abstract Software applications are becoming highly critical in aircraft development lifecycle. They provide the capability and functionalities required to design, manufacture and support aerospace assets of increasing complexity. As such criticality rises, there is a need to implement monitoring and management techniques on software application portfolios, in order to optimise service performance. These methodologies will support industry activities, avoiding operation disruption and mitigating the systemic risks that come with a higher complexity, as well as controlling obsolescence issues over time. This paper seeks to understand the key challenges faced when monitoring software lifecycle and obsolescence over large software application portfolios in aerospace industry. The paper describes results from a series of interviews and workshops with industry experts, as well as meetings with academic experts and literature reviews, to provide a discerning sight on the challenges faced when managing large application portfolios, in terms of complexity and obsolescence. B.V.This is an open access article under the CC BY-NC-ND license © 2015 The Authors. Published by Elsevier B.V. Selection and peer-review under responsibility of the International Scientific Committee of the “4th CIRP Global Web Conference” in the (http://creativecommons.org/licenses/by-nc-nd/4.0/). person of theunder Conference Chair of Dr.the John Ahmet Erkoyuncu. Peer-review responsibility organizing committee of CIRPe 2015 - Understanding the life cycle implications of manufacturing Keywords: Software Obsolescence; System Complexity; Software Lifecycle; Aerospace

1. Background Nowadays, software is increasing its weight in aerospace industry activities, providing unique features and capabilities during aircraft development as well as during its operational lifecycle. When airplanes are produced, it’s not just the sum of its mechanical and electrical components, but a large amount of software components and related services as well. In aerospace, both military and civil, the lifecycle of the assets can be extended for many decades. Due to the high costs and long life times associated with technology insertion and design refresh, aircrafts tend to fall behind the technology wave [1,2]. As such, one critical issue aircrafts will face during its lifecycle is obsolescence [3]. Obsolescence could be defined as when the technology that defines a component of a product is no longer implemented and hence is no longer

available from stock of own spares or being procurable or manufactured [4,5]. Regarding software obsolescence, some people would argue that software applications cannot become obsolete as they are not affected by degradation (and hence do not require replacement) and can be easily replicated. Their misunderstanding is to try to employ the same reasoning to software obsolescence as to mechanical or electrical component obsolescence. It is required to comprehend the different nature of the software obsolescence issue. The significance of obsolescence is that it prevents from maintaining and supporting the system, hence creating a risk of disruption on the operations [6]. Therefore, software obsolescence can be defined as when it is no longer possible to maintain and support an application through time, either because the technology that defines it is

2212-8271 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the organizing committee of CIRPe 2015 - Understanding the life cycle implications of manufacturing doi:10.1016/j.procir.2015.08.013

Raúl González Muñoz et al. / Procedia CIRP 37 (2015) 24 – 29

no longer used and hence is no longer available, or due to variations in the operative/development environment or as a result of changes in the entities that interact with the application, being those either software, hardware or people. Software obsolescence can take place in three main areas, namely skills, Commercial off-the-shelf (COTS) software and media [6], as seen in Fig. 1.

Fig. 2. Systems to be considered when addressing obsolescence [14]

2. Research Methodology

Fig. 1. Types of software obsolescence [6]

“Skills” refers to the knowledge and information required to create, support or modify software. Its loss would inhibit the maintenance of the software. “S/W COTS” software refers to commercial software created by a third party and used by other companies. COTS software becomes obsolete when its supplier drops support. “Media” concerns the data storage materials and formats used to keep the software information. If they are not properly managed and maintained, there is a risk of losing data and information because they can no longer be accessed. During the last years, a number of authors have recognized the importance of software obsolescence, specially related to COTS software [7,8], defence and aerospace [6,9], and later additional long-life assets [10]. The Component Obsolescence Group (COG) has also played a key role, recognizing the importance of this topic and publishing about it [11]. In aerospace industry, as in most of the manufacturing landscape, software applications are grouped in portfolios, which refers to an organization’s collection of software applications and software-based services, which it uses to attain its goals or objectives. These portfolios represent systems of considerable complexity, due to the high number of dependencies among the software applications within it, as well as with other business assets [12,13]. Visualised as a system, software applications can have interactions with many other systems, which must be taken into consideration when addressing obsolescence. Hence, there is the need to assess all the systems involved, as when one of them becomes obsolete, the whole range of systems may become obsolete as well, including the application portfolio and other business assets [14]. A representation of this concept is illustrated in Fig. 2

The research methodology involved three main phases, as illustrated in Fig. 3. The initial phase focused in literature review within the fields of obsolescence, software obsolescence and system complexity. Thanks to this analysis of the state of-the-art, a starting point in the research was established. At the same time, a set of face to face semi-formal meetings and formal interviews was performed with academic and industry experts respectively, being the questions and the topics approached in those meetings aligned with the knowledge obtained from the literature reviewed. The aim of these interviews was to get an insight in how software life cycle is addressed in the industry and the present challenges, being able to contrast this information with the literature available. The profile of the industry participants was as diverse as possible, coming from varied educational backgrounds and with different ages. This was intended in order to gather information from different points of view. There were a total of 13 interviews, being the duration of them between 30 and 60 minutes, depending on the participants and their knowledge. The iteration between literature research and industry interviews helped to provide a clear view of the current landscape regarding software life cycle and obsolescence.

Fig. 3. Schematic depiction of the research methodology

The second phase involved the identification of the different key challenges in software obsolescence, derived from both the literature review and the interviews, and the development of a software obsolescence trigger map, based in previous research and valuable information gathered from

25

26


industry experts. This was presented and validated during a final interview with a key expert from aerospace industry. The third and final phase concerned the creation of a survey with the aim of prioritize the different software obsolescence challenges identified, assigning an order based in the view of aerospace industry experts. 3. Software Obsolescence Challenges and Triggers For this paper, different participants from the aerospace industry and services related have been interviewed. The profile of the different participants that were involved can be seen in Table 1. Questions were asked to find out their understanding of: • Criticality of software in aerospace industry • Major risks in aerospace industry regarding software obsolescence • Current practice to address software obsolescence in aerospace industry Table 1. Experiences of participants interviewed. Participants

Experience

Role

Participant 1

13 years

Service Operations

Participant 2

6 years

Service Manager

Participant 3

8 years

Systems Designer/Project Manager

Participant 4

3 years

Avionics System Engineer

Participant 5

1 year

Production Graduate

Participant 6

5 years

Project Manager

Participant 7

14 years

Application Health and Prevention Manager

Participant 8

1 year

Project Manager

Participant 9

35 years

System Engineering Project Manager

Participant 10

20 years

Service Pack Manager

Participant 11

3 years

License Management

Participant 12

30 years

Security and Obsolescence Manager

Participant 13

20 years

Service Pack Manager Delegate

The answers obtained were compared with the available literature, with the aim to identify the main challenges of software obsolescence within the aerospace field. For that purpose, early research and findings in the areas of component obsolescence [3,4,5] and software obsolescence [6,8,9] were contrasted with specific examples from the participants focusing in the aerospace landscape. As a result of this iterative exercise, twelve main challenges were identified. • Data quality issues (data is not gathered in the appropriate format, it was not stored correctly, etc.) • Data location (data is spread across different isolated sources)

• Disparity of processes and ways of managing the data across different departments/organisations • Existence of long-life projects without obsolescence strategies established from the beginning • High number of hidden dependencies and interactions among different parts of the system (software dependent on other software, software dependent on specific hardware, etc.) • Decreasing control over the skills pool of the organisation (increasing outsourcing of activities, increase in employee’s average age, low hiring rate, etc.) • Security issues due to obsolete software still in usage • High dependency on software suppliers and support provided • Lifecycle of components (software) shorter than the system lifecycle (aircraft) • New functionalities required out of initial scope • Changes in legislation/standards within the industry • Data/files format compatibility and availability across time (keep data available and the capability to work with it) Making use of the information gathered, from both literature review and interviews, and the challenges identified, a software obsolescence trigger map was developed. The aim was to provide an approach to the software obsolescence environment and its causes, taking into account the main interactions and dependencies currently present in the aerospace industry. This map is illustrated in Fig. 4. and comprises three main areas: external constraints, development environment and operative environment. The operative environment is where the software applications are being used, providing service. The applications are grouped in a portfolio by the target company, hence the company that is managing and making use of the applications. Within that portfolio, three main types of software can be found, namely COTS software, in-house developed software and customised COTS software. Within the domain of the target company there can be found five main triggers of obsolescence, common to all the application portfolio. • User skills: It refers to the skills and information to properly use and support the applications • Interacting software: It concerns the other software the application interacts with during its usage. Obsolescence in those interacting pieces of software can cause the application to become obsolete as well, creating the risk of cascade effects within the software application portfolio • Interacting hardware: It represents the hardware that supports certain software. The incapacity of maintaining it may make the supported software obsolete as well • Format, media and storage: It regards the data formats, way of storage and documentation associated. Aircraft have a long lifecycle, and during all this time span all the original data needs to be accessible, in order to be able to support the aircraft during its operational life and to be responsive to external requirements


27

Fig. 4. Software obsolescence trigger map

• Ecosystem compatibility: It concerns the compatibility of each of the applications with the whole environment of the target company domain. This encompasses a wide range of business assets and processes Regarding in-house developed software, its specific obsolescence trigger would be between the operative environment and the development environment, as it lays in between its usage and its development. • In-house developer skills: It refers to the skills of the target company developer to develop and maintain in-house developed applications The development environment is where the software applications are developed, maintained and improved. It encompasses mainly two different domains, the software supplier domain and the third party support domain. The software supplier refers to the original developer and seller of the COTS software, as well as its customisations in some cases, the target company is using. Within its domain, three different obsolescence sources can be found. • Development: Obsolescence can start to take place in the development process itself due to different reasons, as delays and technological wave • Official updates and support: The lack of updates and support from the original developer may be as well a cause of obsolescence, as even with a third party support, the access to a certain tools or the code may not be possible without the original supplier • New version release: The release of new versions of software can produce obsolescence, depending on the

support policy, the new formats and the existing infrastructure The third party support refers to the contractor the target company hires to provide support in activities related to the management of the application portfolio. It may be the original developer of the software, or it may not. Under its domain, two different triggers can be found. • Contracting mechanisms: depending on the characteristics of the agreement between the target company and the third party support, issues may rise in the future and be a cause of obsolescence. This refers mainly to the, eventually, lack of support during a period of time not considered initially, or unexpected situations not considered in the original agreement terms • Support skills: It refers to the skills required to support and maintain the software applications. If the third party support has problems locating and keeping professionals with the required set of competencies, this situation may evolve into obsolescence, due to the inability of providing proper support to the applications External constraints refers to the different drivers that act over the industry environment and that are completely external to the organisations. They have a big scope and involve all the companies within an industry field. • Industry standards: Changing standards within an specific industry field may cause obsolescence in software, as some of the applications may not be aligned with the new requirements

28


• Industry legislation: Changes in regulatory laws and policies can turn software applications obsolete, usually because a mismatch with the new requirements • Market skills pool and educational programs: Obsolescence can come from the degree of availability of professionals with certain skills. This availability comes from different factors, mainly the current content of educational programs. For example, certain code languages are not being taught anymore, but there are still a lot of applications, built in those languages, operating nowadays • Availability of hardware required for specific software: Certain software requires of specific hardware to work. Hence, the availability of this hardware in the market is important, due to the dependency relation. The stop of official production can be mitigated with alternative and second-hand markets, but it’s still just a mitigation, not a long-term solution • Availability of software alternatives: The degree of availability of software alternatives for certain functions can be a key driver for obsolescence. The lack of availability of software alternatives may cause obsolescence and/or make it worse, if the original software becomes obsolete for any reason

Participant D

20 years

Software Developer

Participant E

20 year

Robustness Services

Participant F

5 years

Project Manager

Participant G

14 years

Application Health and Prevention Manager

Participant H

5 year

Service Portfolio Manager

Participant I

35 years

System Engineering Project Manager

Participant J

20 years

Service Pack Manager

Participant K

3 years

License Management

Participant L

30 years

Security and Obsolescence Manager

Participant M

20 years

Service Pack Manager Delegate

Participants were prompted to score, based in their knowledge and experience, each of the twelve software obsolescence challenges identified. The score was assigned within a scale from one to five, taking in consideration the importance of the challenge, thus its business impact. The results of the survey are depicted in Fig. 5.

The capability of the target company to mitigate obsolescence will vary depending on the environment. Hence, the target company will have a considerable control in its own domain, being able to monitor and act over the obsolescence triggers. However, this capability will be limited in the domains of the software supplier and the third party support, and will depend in the agreements in place between all the stakeholders. Finally, this lack of control becomes more evident in the case of external constraints, as usually the target company is able just to adapt to the changes, being limited in the pro-activeness of its approach. The inherent complexity of this landscape can be easily perceived in Fig. 4., as there is a large number of dependencies and interactions among the different components and sub-components of the system. 4. Business Impact and Prioritisation Once obtained a number of key challenges in software obsolescence and a representation of the different possible triggers, within the aerospace industry, a survey was conducted among 13 industry experts. The aim of the survey was to establish the importance of each software obsolescence challenge in terms of business impact. The sample of participants was very similar to the one of the interviews, just differing in four participants, as seen in Table 2. Although, the intention still was to encompass different profiles, even if most of them belonged to ICT field, due to the very specific nature of the survey. Table 2. Experiences of participants from the survey Participants

Experience

Role

Participant A

13 years

Service Operations

Participant B

6 years

Service Manager

Participant C

5 years

Maintenance and Support

Fig. 5. Software obsolescence challenges business impact

From the results of the survey, several comments can be provided, especially regarding the first four challenges. The key challenge that raises more awareness is the High number of hidden dependencies and interactions among different parts of the system. This aligns with one of the main aspects of the software obsolescence trigger map, shown in Fig. 4., that is the inherent complexity of interactions between the different entities within the landscape. The second by importance would be the disparity of processes within different departments. This could be related to the compatibility of the ecosystem within the target company domain, as well as with the software supplier domain and the third party support domain, suggesting lack of communication or presence of silo effect.


The third ones would be Data/files format compatibility and Existence of long-life projects without obsolescence plan in place. This relates with format, media and data storage in the trigger map, and with a historical lack of understanding towards software obsolescence, which corresponds with the reality of the industry, as it’s a topic that started to be focus of research quite recently. The fourth would be Lifecycle of components shorter than lifecycle of the system. This is a recurrent issue in aerospace industry, as the time span of the aircrafts can be extended for decades, making critical the availability of support for all the components of the system, including software. The first challenge is linked with the interactions of the system, but since all the rest of the answers are linked just with the target company domain, it’s likely that participant’s vision of system is limited to the immediate environment of the target company, no possessing a view of the full scope of the present interactions. Moreover, important challenges that belong to other domains and that had been already point of research, such as dependency from COTS software, don’t seem to raise that much of awareness among the industry experts involved in the survey. This suggests a focus in the operative environment, remarking a lack of accurate understanding, of the different interactions and dependencies among diverse components of the obsolescence landscape. Hence, this supports the idea that in general terms, the industry, lacks of a precise picture of all the interactions that drive software obsolescence, but it is aware at least of the existence of this layout, and of the risks that it represents for the business. This strengths the need of a clear identification and mapping of the underlying interactions, among the different components within the obsolescence landscape. Hence, it remarks the value of proposals such as the Software obsolescence trigger map, enabling the identification of the key entities and aspects that drive software obsolescence, as well as its interactions. 5. Conclusions Software is acquiring an increasingly important role in aerospace industry. One of the key challenges the companies will have to face, due to the long time span of aerospace assets, is obsolescence of software applications. In order to face this challenge there is the need to understand the nature of the software obsolescence drivers for aerospace industry, and which are the interactions among them. In the present paper, a set of key challenges when facing software obsolescence has been presented, and later evaluated through survey by industry experts. Additionally, a software obsolescence trigger map has been developed, with the aim of showing the scope and drivers of the software obsolescence landscape in aerospace. Hence, the key results are: • Main key challenges of software obsolescence in aerospace industry • Software obsolescence trigger map for aerospace industry

These results will help both industry and academia to understand the particularities of software obsolescence within the aerospace field, providing as well a starting point to identify and establish a future control over the different causes of software obsolescence. Future research in the area should involve the creation of monitoring systems based in those obsolescence drivers. This will enhance the capabilities of aerospace companies to manage software application portfolios, avoiding business disruption and optimising maintenance cost. Acknowledgements This research project is funded by Airbus and Cranfield University. The author would like to gratefully acknowledge the support and assistance from many staff of Airbus and several aerospace organisations during the research. References [1] Sandborn, P., Mauro, F. and Knox, R., 2007, A data mining based approach to electronic part obsolescence forecasting, IEEE Transactions on Components and Packaging Technologies, 30; 3; 397-401. [2] Madisetti, V., Jung, Y., Khan, M., Kim, J. and Finnessy, T., 2000. On upgrading legacy electronics systems: methodology, enabling technologies and tools, VHDL International Users Forum Fall Workshop, 2000. Proceedings, Orlando, FL, USA, 18-20 Oct.: 7-14. [3] Condra L (1999) Combating electronic component obsolescence by using common processes for defense and commercial aerospace electronics. IECQ-CMC Avionics Working Group1, NDIA, September 1997. [4] Singh P, Sandborn P, Lorenson D, Geiser T (2002) Determining optimum redesign plans for avionics based on electronic part obsolescence forecasts. Proceedings of the World Aviation Congress, November 2002, Phoenix, AZ, SAE International [5] Solomon R, Sandborn P, Pecht M (2000) Electronic part life cycle concepts and obsolescence forecasting. IEEE Transactions on Components and Packaging Technologies 23(4):707–717. [6] Romero Rojo, F.J., Roy, R., Shehab, E., Cheruvu, K., Blackman, I. and Rumney, G.A.. Key Challenges in Managing Software Obsolescence for Industrial Product-Service Systems (IPS2). The 2nd CIRP Industrial Product-Service Systems Conference, Sweden, 14th–15th April 2010. [7] Sandborn, P., 2007b. Software Obsolescence - Complicating the Part and Technology Obsolescence Management Problem. IEEE Transactions on Components and Packaging Technologies, 30; 4; 886-888. [8] Merola, L., 2006, The COTS software obsolescence threat, Fifth International Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems, 13-16 Feb. 2006. San Diego, CA. [9] Rajagopal. S., Erkoyuncu, J.A., Roy, R., Software Obsolescence in Defence, Procedia CIRP, Volume 22, 2014, pp 76-80, ISSN 2212-8271. [10] Erkoyuncu, J.A., Ononiwu, S., Roy, R., Mitigating the Risk of Software Obsolescence in the Oil and Gas Sector, Procedia CIRP, 22: 81-86, 2014. [11] Rumney, G. A., 2007, The Software Obsolescence Minefield: A Guide for Supporting Software and Electronic Information, 1st ed., COG International Ltd., UK. [12] Waite, E.J., AIT — Advanced Information Technology for Design and Manufacture K. Kosanke, J.G. Nell (Eds.), Enterprise Engineering and Integration: Building International Consensus, Springer-Verlag, Berlin (1997), pp. 256–264. [13] Remington, K., R. Zolin and R. Turner (2009). “A model of project complexity: distinguishing dimensions of complexity from severity”. Proceedings of the 9th International Research Network of Project Management Conference, IRNOP, 11–13 October 2009. [14] Dowling T (2004) Technology insertion and obsolescence. Journal of Defence Science 9(3):151–155

29