Packageability as an ‘Ility’ for Systems Engineering

Abstract

The usefulness of packageability as one of the ‘ilities’ for systems engineering was investigated. It was found that packageability plays an important role in a multitude of systems, and it was investigated in several ways. First, a brief analysis showed that at least two criteria must be met for something to be considered an ility. These criteria are that the ility often manifests itself after the system is deployed, and that the potential ility must not simply be a persistent physical characteristic. It was shown that packageability meets both requirements. Second, six different systems were examined, revealing nine general ways packageability is used. They provide a way for system engineers to recognize packageability as a non-functional system property. The usefulness of packageability as a top-level non-functional system property is shown, as well as for sub-systems and components. A working definition of packageability is then proposed. Finally, a detailed treatment of packageability is presented for radar systems with transmit–receive modules. Packageability was shown to be a useful ility category that can add value to stakeholders, and that captures real system features that are not captured by other ilities. This work demonstrates that packageability should be considered as an ility for systems engineers.

1. Introduction

Ilities are life cycle properties of a system. They should not be confused with the primary functional requirements of a system which describe how it performs. Rather, ilities “typically concern wider system impacts, with respect to time and stakeholders, that are embodied in those primary functional requirements” [1]. Typical examples of ilities are quality and safety, which are not functional requirements, but are, nevertheless, real system properties of importance to stakeholders. In the airline industry, for instance, safety is a concern for aircraft manufacturers, airline operators, passengers, employees, government agencies, and airport operators, but the specific functional requirements related to safety may be different or at least expressed differently, for each group. Each stakeholder group has needs which can be captured using ilities. The ilities of a system are often called life cycle properties. Thus, in this work, we treat these two as interchangeable synonyms.

The relationships between ilities and the system properties that they describe have been the subject of active research. For instance, the benefit of using ilities for analysis of stakeholder needs was examined in [2]. It was found that a benefit of using ilities in early system trade studies is that they can avoid premature translation of perceived stakeholder needs into design requirements—thereby missing end-user priorities.

A similar approach was taken in [3], by developing a method for architecting systems of systems (SoS) using ilities. The method uses specific steps and analytic tools for identification and inclusion of applicable ilities in the concept stages. It was found that including ilitiy-driving options early in the architecting stages improved stakeholder value sustainment through the full system life cycle. In their approach, ilities drive requirements. Ilities were shown to not only be useful in the system concept and development phase, they were also recognized as a way of assessing end-user acceptance of systems. This was also the point in [4], as applied to software systems. The benefit of ilities in software systems was also considered a way to ensure the system is fit for its purpose of meeting end-user expectations. These diverse examples share the common idea that ilities can be integral to concept development and architecting of systems, and are useful through the complete system life cycle.

In addition to describing the life cycle properties of a system, an interesting characteristic of ilities is that they flow down as properties to the subsystem and even component level. For instance, the system characteristic of quality does not exist in isolation at the top level of the system. Rather, quality is passed down as a property to the lower parts of the system. It may be converted to requirements at the subsystem level, or remain a property until passed down to the component level, or even to the parts level. This is illustrated in Figure 1. For instance, the system property of reliability can exist at the system level as a property, and pass to the subsystems level as a property. However, further into the system, the property of reliability is translated into specific functional requirements. This is also true of safety, flexibility, durability, and testability, to name a few. While ilities are first a system-level property, they can also remain properties of subsystems and even components until they are translated into requirements.

With this ground work on ilities, the focus of this work is on packageability as a useful ility for systems engineering. The concept of packageability touches on many different disciplines. For instance, it has been used in the poultry industry [5,6], transportation industry for electric vehicle engines [7], electronic display industry [8], transportation industry for passenger restraint systems [9], electronics industry for integrated circuits and higher-level modules [10,11], and the transportation industry for internal combustion engines [12]. These diverse examples (most of which will be described in more detail in Section 2) demonstrate how packageability is used in a variety of industries to describe non-functional properties.

However, despite the widespread use of packageability to provide non-functional descriptions of systems, it does not appear in lists of ilities for systems engineering. For instance, in [1], a list of 20 ilities is provided and analyzed that does not mention packageability. In [13], the author uses eight different ilities for systems, but does not mention packageability. While in [14], the authors identify 56 different ilities of concern to systems engineers, but do not mention packageability. Despite not being mentioned in the systems engineering literature, as already shown, packageability has been used as a system descriptor. Since packageability is widely used in industry, but not yet widely used in systems engineering, this work demonstrates its utility and why its use by systems engineers is beneficial.

This work is divided into six sections. Section 2 provides results which support the idea that packageability should be considered an ility. This is accomplished by examining six different examples of it as a non-functional property. Section 3 describes nine common characteristics of packageability. Four possible objections to the characteristics of packageability are considered in Section 4. Section 5 provides a working definition of packageability, based on the case studies and characteristics. Section 6 shows why packageability should be considered a life cycle property. This is done by showing that packageability is often achieved only after the system is deployed, and that it is not restricted to describing persistent physical factors, such as size and weight. Section 7 describes how packageability is applied to phased array radar systems. Section 8 provides a short summary and conclusions.

2. Results: Demonstrations Showing the Usefulness of Packageability as an Ility

This section presents six examples of different systems which use packageability as a description for some of their non-functional properties. The examples were briefly introduced in Section 1 and are considered in more detail in this section. The goal is to use these examples to further demonstrate the usefulness of packageability as a non-functional requirement.

2.1. Power Transmission Systems in Hybrid Electric Vehicles

Packageability has been used to describe the ability to balance performance requirements with the reduction of the number of components for power transmission systems used in hybrid electric vehicles [7]. The transmission system maximized power delivery efficiency, system weight, and fewer components, resulting in the property of packageability in the system.

2.2. Electronic Displays

Packageability, along with reliability and stability, has also been described as a non-functional requirement for electronic displays [8]. In this example, packageability was used to describe the property of being easily integrated or assembled, and includes the ideas of lower complication and being less cumbersome, which are important stakeholder needs.

2.3. Passenger Restraint Systems in Vehicles

Another example is [9], in which packageability is used to describe a passenger restraint system fabric used in vehicles. In this case, it refers to the balance in the system so that it has the ability to be contained in a small space and the ability to properly restrain during operation. In other words, stakeholders such as car drivers, passengers, manufacturers, and car dealers desire a balance between small space for their restraint systems and the ability of the restraint system to operate properly. This balance is the packageability of the restraint system.

2.4. Integrated Circuits and Modules

In [10], packageability is applied to the integrated circuit and higher-level modules, and includes “global optimization” and the balancing of “system performance and cost, prior to committing major engineering resources and capital”. A benefit, in this case, of considering packageability is the optimization of the complete system. In [11], a similar approach is taken, where packageability is used to describe the property of electronics to achieve the right balance of miniaturization, reliability, assembly ease, efficiency, and electrical characteristics. In this case, packageability describes non-functional requirements of a subsystem/component called a multichip module (MCM), operating at microwave frequencies. Another example is the packageability of high speed optical networks which have interconnects, thermal factors, mechanical stress, material compatibility, size, and cost. The balance of these (and other) requirements is captured by the packageability of the system. In these examples, packageability describes a system property which balances multiple requirements to achieve stakeholder needs.

2.5. Internal Combustion Engines

Another example is in [12], which describes a variable lift system for internal combustion engines. In this case, it describes the non-functional mechanical property of ease of integration.

2.6. Satellite Systems

In [15], packageability is applied to the systems engineering of earth observing satellites. The authors examine packageability not just for a single satellite, but as it impacts overall systems engineering of a complete program with multiple satellites. The idea is that packageability impacts overall program optimization, cost, and scientific benefits.

3. Characteristics and Working Definition of Packageability

The examples developed in the prior section provide insight into some of the ways that packageability is used as a non-functional property. Based on these examples, nine characteristics of packageability have been generated, and a working definition has been developed. It should be kept in mind that the nine characteristics are not meant to be an exhaustive list, since there are surely many other properties of packageability. Also, it is important to remember that any particular system with the non-functional property of packageability does not need to display all nine characteristics.

3.1. Mechanical Fit

This is more than just achieving a particular size requirement. It is an optimized mechanical configuration. In other words, for some systems, part of the packageability property is that a balanced design (among the other characteristics of packageability) is achieved, which includes a particular mechanical fit.

3.2. Minimized Complexity

Packageability includes the idea that the product has the property of having only the level of complexity necessary to meet stakeholder needs. Often, this property is not verified until the system is deployed.

3.3. Less Cumbersome

This concept is more abstract, but is based on the idea that the system is smaller, lighter, efficient, more manageable, convenient, and easier to transport.

3.4. Ease of Assembly/Integration

This concept addresses that all systems must be fitted together in many different ways, including mechanically, and electrically, with their deployed environment, software wise, and integrated into the user lifestyle. The ease of being fitted together in a holistic and big-picture fashion is incorporated in the definition.

3.5. Interconnect Performance

Packageability is used to describe the property that interconnects (such as electrical) have been optimized within the scope of other system requirements such as cost, heat transfer, electrical bandwidth needs, and overall reliability.

3.6. Thermal Performance

When packageability is applied to some systems, an important aspect is that thermal performance has been balanced with other requirements to achieve overall stakeholder needs, such as reliability. Often, this system level balance is not recognized as being achieved until the system has been deployed (usually in varied use cases) to verify thermal performance. An example is the packaging of a vehicle engine in such a way that it can perform in a variety of weather conditions and from hot to cold climates.

3.7. Fabrication Ease

The claim that a system is packageable also means that it has the property of fabrication ease, balanced against other stakeholder needs.

3.8. Shipping Ease

For some systems, packageability includes being able to be shipped a single time and then deployed. For other systems, this means multiple shipments. In other words, the packageability of some systems means that they have the property of being able to be shipped, used, and shipped again. The ability of the system to be successfully shipped or re-shipped is an indication of its packageability.

3.9. Balance

An important aspect is that the system is balanced, considering multiple stakeholder needs. Balance is achieved when the right emphasis is placed on each of the packaging properties to meet stakeholder needs.

4. Possible Objections

There are four possible objections to these as characteristics of packageability. We will consider each of them.

The first objection considered is that assembly/integration ease (Section 3.4), fabrication ease (Section 3.7), and shipping ease (Section 3.8) can be measured on an effort scale for a particular implementation, rather than part of a general characteristic of an ility. However, this objection is not valid because ilities themselves, and characteristics of ilities, can be measured on a scale. Consider the example of safety which is widely regarded as an ility. MIT Professor O. L. De Weck states, “The early development of automotive braking and many early developments in airplanes are tales of safety becoming a consideration … of ilities” [1]. The idea that safety is a non-functional requirement of a system is also shared by airline travelers. Yet, airline safety is measured on a scale. The JACDEC safety index, for instance, provides a probabilistic measurement of past airline safety [16]. This is an example of a widely recognized ility that is measured on a scale. Moreover, consider how a characteristic of an ility can be measured along a scale. The definition of reliability provided in the Systems Engineering Body of Knowledge (SEBOK) includes “the probability of a system or system element performing its intended function under stated conditions without failure” [17]. Note that this definition uses the characteristic of failure. Yet, it is widely recognized that failure can be measured and quantified for specific systems—consider the failure rate of a particular component in a system. This demonstrates that a characteristic of an ility can be measurable on a scale. Therefore, there are good reasons and prior work that support the proposal that characteristics of ilities (and indeed ilities themselves) can be measured along a scale.

The second possible objection is that the characteristics in Section 3.4, Section 3.7 and Section 3.8 describe how well an ility is manifested in a particular system, and so they should not be included in the definition of an ility. This point is similar to the prior one, except this objection emphasizes that an ility characteristic should not describe how well the ility is manifested in a particular system. However, this objection is addressed by considering the ility of maintainability. The SEBOK describes it as “the probability that a system or system element can be repaired in a defined environment within a specified period of time” [17]. Note that the definition of maintainability entails how well it is manifested in a particular environment and within a set period of time. This indicates that the characteristics of an ility can describe how discernible it is for a particular system. For this reason, this objection can be rejected.

The third possible objection is that minimized complexity is a means to an end, and so it should not be considered a characteristic of packageability. However, other ilities are described with similar characteristics. Consider the ility of usability of software systems, which has the characteristics of “increased productivity, decreased user training time and cost, decreased user errors, …” which improve the bottom line of businesses [18]. These characteristic benefits are similar to the minimized complexity of packageability, in the sense that they are the optimized, best, or most effective instances of a particular characteristic—but optimized in a subjective and not absolute sense. This is an important distinction of ilities, which can be “subjective and not absolute” [19]. Yet, they can still be minimized or maximized. For these reasons, minimized complexity is a valid characteristic of packageability.

The fourth possible objection is that balance is a broad characteristic of any properly engineered system, and so it should not be included in the definition of packageability. While the authors do agree that balance is a common requirement for most systems, this does not negate that fact that it is still an important feature of packageability. In other words, the idea that a characteristic is common and, therefore, not important, does not follow. Therefore, this objection is a case of faulty logic. Common characteristics can still be very important and balance is an important characteristic of packageability.

While there may be other objections that can be levied against the characteristics of packageability, a few have been considered and addressed.

5. Working Definition

In developing a working definition of packageability, it is important to keep in mind that ilities are defined in general, rather than specific, terms. Consider, for instance, the definition of reliability. When applied to systems, it is defined as “the successful operation of the system throughout its planned mission” [19]. Taking this approach of a general definition and the analysis in Section 2, packageability is defined as the ability of the system to achieve a balance of mechanical and non-mechanical properties for the duration of its life cycle. For many systems, this entails an optimized balance of multiple and often conflicting, properties or requirements, including mechanical fit, complexity, cumbersomeness, assembly, interconnect, thermal, fabrication, and shipping needs.

6. Packageability as a Life Cycle Property

As mentioned previously, ilities are non-functional life cycle properties of systems. The purpose of this section is to show that packageability possesses the two main characteristics typical for ilities. This is important as it provides additional reasons to consider packageability a valid ility for systems engineering.

The first characteristic of ilities is that they often, but not necessarily, manifest themselves after the system has been deployed. On the one hand, it is easy to see how packageability can be achieved prior to deployment. An example is the previously mentioned packageability of electronic display, where the displays achieve the property of packageability when they are less complicated. Various design alternatives for the electronic display can be compared and the option with fewer complications can be chosen. On the other hand, packageability also refers to system properties that cannot be noticed until the electronic display (such as a smart phone or tablet) is deployed, such as being less cumbersome. Users of portable displays, for instance, will notice the display is convenient to use and has the property of a good balance between weight, size, and ease of transportation. The point is that some of the system properties are only noticeable after customers begin to use the display.

Another example is passenger restraint systems, where the non-functional properties desired by stakeholders are only noticeable after deployment. For instance, passengers only notice that the restraint system has the balance of size and ability to restrain when the system must restrain during a collision. The car dealer selling the car (who is an important stakeholder) has the need of a compact restraint system which will sell cars. While a more complicated restraint system (such as those worn by competitive drivers) may maximize the property of restraining, such a system will not sell cars. The car dealer only knows that the system has the right balance of size and ability to restrain when customers purchase vehicles. Packageability in this restraint system example is not solely the size of the system, or the ability to restrain, but it is the balance between these and other features which packageability entails. These examples describe how packageability captures non-functional system properties which are only noticed by stakeholders after the systems have been deployed.

The second important characteristic of ilities which packageability must possess, is that they entail factors that must not simply be persistent physical characteristics. For instance, primary functional requirements related to size and weight by themselves cannot be considered ilities [1]. Instead, for some systems, packageability refers to the balance of physical characteristics in a design, and the balance is often only noticeable or confirmable after deployment.

Consider, for instance, the property of packageability applied to a high-speed optical backhaul link. A portion of the packageability is not noticeable until the systems are deployed and the stakeholder needs of a balanced system meeting data rate (packageability of the electronics) and reliability (packageability of the heat transfer system) are realized. Other packageability properties of the optical link are evident earlier in the life cycle. For example, the ease of assembly is realized during assembly of the system and is not a persistent physical characteristic of the system. Packageability in this example is observable as a system property after the system has been put into initial use, and at earlier times in the system life cycle, but is not simply a persistent physical factor.

As noted in [1], life cycle properties have social factors. In fact, the systems engineer must have a deep appreciation of how social factors create and define which life cycle properties will meet stakeholder needs. This is certainly the case for packageability because our society is driving systems solutions for high levels of performance in the same or smaller foot print. As a result, packageability as a life cycle property is being driven, at least in part, by social factors.

7. Detailed Application of the Proposed Approach: Packageability of Phased Array Modules

Phased arrays are systems used in radar and communication applications. Active electronically scanned arrays (AESAs) are a type of phased array used in military radar systems such as airborne radar platforms. Figure 2a shows an image of an F/A-18E/F fighter airplane and illustrates that the radar is contained within the nose of the aircraft. Packageability is a valid non-functional system property of these systems, and this section considers it applied to AESA for airborne military radars.

An example of how the radar system is contained within the nose of the aircraft is shown in Figure 2b [20] for the Euroradar CAPTOR mounted onto a Eurofighter Typhoon. As can be seen, the radar system includes the radar antenna, receiver/exciter, and computer processors. In the radar antenna portion, over 1000 transmit/receive (T/R) modules are contained, which perform the functionality that enables the features and performance of the system.

Packageability as a non-functional property of an AESA will be examined for the system as a whole, and for the T/R module subsystem contained in the radar antenna. The systems engineer must ensure that the phased array will be an optimized balance of multiple properties. This includes mechanical fit balanced with other stakeholder needs, since the array must be configured and balanced to be contained within the restrained space provided. The system engineer must balance not only the mechanical fit, but many other stakeholder needs such as reliability, safety, and sustainability, to name a few. This balance, not the mechanical fit as a standalone feature, is an example of packageability. Another system example of packageability is the balance that must be achieved in thermal performance. The phased array generates significant heat, and the heat must be removed so that the electronics meet the stakeholder need for reliability. However, the thermal solutions must be balanced against other stakeholder needs such as system cost, weight, and mechanical fit, to name a few. For instance, it is typical for these types of systems to use liquid cooling. The cooling system can be heavy and requires the circulated liquid to be pumped and cooled. The cooling system cannot be optimized in isolation without balancing other user needs. When the thermal solution is optimized in the context of the other stakeholder needs, then the non-functional property of packageability is achieved.

As mentioned earlier, it is sometimes advantageous for the systems engineer to carry an ility not only at the system level, but also down to the subsystem, or even component level, before conversion into functional specifications. One reason for doing this is that it allows the systems engineer to pass important stakeholder needs to designers, without restraining specifically how the need will be met. Packageability is an ility that can be passed to the T/R modules in a phased array and the conversion of that need into requirements and specifications can be left to the designer.

Consider the T/R module shown in Figure 3, which possesses several of the nine characteristics of packageability developed in Section 3. First consider how the T/R module design must be balanced. Note how the module has multiple competing requirements related to high frequency interconnects, heat dissipating integrated circuits, dissimilar materials, coupling between circuits, and module level resonances, which must all be balanced to achieve packageability. Second, it has electrical interconnects that must function well at microwave frequencies for the system to meet user needs. Third, it has thermal performance concerns, since there are several integrated circuits which generate significant heat flux (over 3000 W/cm² as shown in [21]), and that heat must be removed using methods which do not reduce the integrity of the radar signal. Fourth, the module has the characteristic ease of assembly at the module level itself and when integrated into the next level. Fifth, the module and its components and parts have the characteristic of mechanical fit. This is not only true of the module and its internal features, but also the module itself into the next level assembly, and how this property flows through the rest of the system. This shows how the T/R module exhibits a few of the characteristics of packageability given in Section 3.

In addition, the components in the module may have dissimilar thermal expansion rates, yet their connection must remain reliable. Other issues include coupling between circuits, and resonances of the radar signal in the module. The systems engineer must be aware that these types of packaging issues exist and must pass the packageability property of the system down to the subsystem and component level. Additionally, they must ensure that designers perform the correct trade analysis to optimize all the stakeholder needs. This type of optimization is the point in [10], which shows how design for packageability must permit a global optimization of the entire system, but with details even down to the integrated circuit level. This also speaks to the characteristic of a balanced and minimized complexity solution.

The phased array radar example demonstrates how packageability is a relevant ility for systems engineers to add to their list of ilities.

8. Conclusions

Ilities as non-functional system properties are an important part of successful system design. This point is missed by some system designers, and the result can be that systems are developed and deployed that do not meet customer expectations. In some cases, this may result in parts of the system being redesigned, often at great expense. One of the functions of the systems engineer is to translate the ilities into specifications and requirements. One purpose of this work is to provide systems engineers with an additional ilitity that can be added to their tools for correctly capturing customer needs to translate into requirements.

Therefore, this work makes the case for packageability to be considered a valid ility for systems engineers. It also shows the importance of packageability by considering how it is evident in multiple systems. Nine different characteristics of packageability were extracted from the example systems, and a working definition was given. A detailed example of how packageability is relevant to phased array radar was described.

The conclusion of this work is that packageability does meet the two requirements for an ility, and example systems do use it to describe non-functional properties. As a result, packageability should be considered a valid ility for systems engineering.