Is There Any Value In Software Product Lines For Aerospace and Defense? Part 1 In A Series On SPL For A&D




Blog by Steve Denman, Product Marketing Consultant, PTC 

Can aerospace and defense companies benefit from implementing software product line techniques and tools? Where’s the SPL ROI in the A&D industry, if there is one? In this blog series, we’ll examine the SPL practice and consider its potential value and risks in this specialized world of complex, high-consequence products and systems.

Before we start into the topic, it might help to begin with a definition:

“Software product lines (SPL) refers to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production.” –softwareproductlines.com

There are a few other definitions in use today, some are nearly identical, others close enough. So, we’ll use the definition above, posited by Dr. Charles W. Krueger, CEO at BigLever Software, on the Software Product Lines web site. This definition clearly points out the three characteristics (highlighted in bold font) that make SPL a definable practice. It is the common means of production that really sets the SPL practice apart from previous attempts at software reuse and gives us reason to believe that it will work, this time.SPL techniques are getting considerable attention lately in multiple market sectors, including electronics & high tech, automotive, medical devices, and, not to be left behind, aerospace & defense, with the later sector the primary focus of this blog. In fact, the Software Engineering Institute thought it was important enough to create a whole new practice area for it (see SEI SPL Practice) and a number of new and existing companies have jumped in with methods and tools to address various aspects of it (more on this in a later posting).

SPL is already being applied extensively in automotive manufacturing, where suppliers have transformed in the past several decades from mass manufacturing metal parts according to clearly understood mechanical specifications into engineering complex software-intensive modules with hundreds of variations, one for each customer’s unique combination of brand, model, engine configuration, drive train configuration, and so on. Reuse is already a way of life in this industry because survival depends on it, and numerous companies in this space are claiming success from applying SPL techniques.

The question for us is whether this also applies to the business of aerospace and defense. After all, we don’t typically create hundreds of product variants, sell to millions of customers, or manufacture millions of units. Despite our focus on cutting cost, we aren’t trying to squeeze the last dollar out of per unit manufacturing cost. However, contractors and suppliers in this industry increasingly face a number of challenges to doing business as usual, not the least of which are:

• Dramatic increases in volume of software in our systems and products, due to increasing reliance on software for product innovation;

• Growing customer bases in order to further amortize the staggering engineering investment required to develop products and increase profit margins, which leads to the need to support more product variants than ever before; • Mounting pressure to deliver more complex products in less time and at lower per unit cost;

• Ever more stringent compliance requirements, which in combination with increasing use of software in products, is significantly driving up engineering cost; and

• Product failures receiving much greater attention from the public, leading to huge adverse impact on our bottom lines from ever-increasing litigation settlements and damage to public image.

So, I submit that the SPL practice is equally valuable in our industry and intend to illustrate this in the coming weeks with a series of postings on the topic, addressing questions like:

• What’s really different about SPL as compared to previous attempts to foster reuse across product lines?

• How are specific SPL practice areas being applied in development and maintenance of A&D products and systems?

• Who’s out there changing the game with novel tool and methodological approaches to SPL?

• Can SPL coexist with the emerging practice of Model-based development (MBD) in A&D? • Can we use SPL in the rigorous DO-178 certification environment?

• What effect will SPL have on compliance with the many other standards common in our industry (e.g., ITAR, CMMI, ARP-4754, and STIGs)?

Please join me in the coming weeks as we explore these questions. I’ll tweet each new installment in the series, so you can be reminded of new posts and participate in the discussion with your opinions and questions by following me on Twitter @sddinabq.