CHAPTER 7

Case Studies

7.1 Introduction

This chapter presents the case studies we use to help evaluate our hypothesis. It is spilt up into five subsections; each describing the experiments and results for the five nominated architectural styles described in Chapter 6. For all experiments, data and results from statistical analysis can be found in Appendix G.
7.2 Case Study 1: Main/Subroutine
Increasingly washing machine manufacturers are turning from mechanical and simple electronic systems that control the wash cycles to more complex instrument control units run by software. Our first experiments are from an application family of washing machine cycles1 that have implementations based on a Main/Subroutine architectural style. A washing machine cycle is a wash-program that a user can select from a control panel. Washing machines usually have a range of wash cycles for different types of fabric, including a boil-wash for white linen, a fast-coloureds wash
Although our specifications for a family of washing machine cycles is based on information taken from Zanussi documentation, our solutions are completely independent of Zanussi. Any resemblance to their actual products is coincidental.
cycle for cotton, a mixed-fabric wash cycle, and a cool wash cycle for woollens. Each wash-cycle typically consists of a number of phases, which might include a pre-wash phase, a main-wash phase, a rinse phase, a spin phase, and a drying phase. Typically a control panel on the front of a washing machine lets a user select a desired wash cycle. A users requests will be evaluated by the software, which in turn will control the washing machines hardware. The software monitors the progress of the hardware and the states of the machine are relayed back to a control panel informing the user. Figure 7.1 shows the relationship between the embedded software and the hardware.

Hardware

Control Panel Embedded Software
Figure 7.1: Washing machine system layout We have constructed an MRAM application family model for a single washing machine cycle that may exist as a part of a washing machines embedded software. The application family model is based on features found in Zanussi documentation [7.1] and [7.2], and is detailed in Appendix B.1. It has thirteen points of variability (discriminants), including:
A wash cycle shall have different phases including a pre-wash, a main-wash, a rinse phase, a spin phase and a tumble-dry phase multiple adaptor discriminant.
Different pre-wash phases that work at different temperatures single adaptor discriminant.
Different main-wash phases that work at different temperatures single adaptor discriminant.
Different tumble-dry phases shall spin the drum at different speeds single adaptor discriminant.
There shall be an optional rinse-hold, eco-wash and reduced-spin facility optional discriminants.
Indicator lights shall display the progress of a wash cycle on the control panel optional discriminant. An application family design was built to realise the features in the application
family model (See Appendix B.1.1).
This design takes the form of a Yourdon
process-flow diagram [7.3]. Design notations are described in Appendix A.2. Points of variability in the application family design are modelled using our patterns from Chapter 4.
7.2.1 Main/Subroutine Experiments
Five requirements specifications were derived from the application family model for five different washing machine cycles. Each specification incorporates a different amount of variability:
System 1 is a rinse cycle incorporating two points of variability. (Appendix B.2). System 2 is a low-temperature tumble-dry cycle with a delayed door release, incorporating four points of variability. (Appendix B.3).
System 3 consists of a low-temperature main-wash cycle with a rinse phase, also incorporating four points of variability. (Appendix B.4).
System 4 is a medium-temperature main-wash cycle, which includes pre-wash, main-wash, rinse and spin phases, incorporating seven points of variability. (Appendix B.5).

System 5 is a full, high-temperature wash and dry cycle, incorporating 10 points of variability. (Appendix B.6). For each of the five system specifications we constructed two designs, each with
corresponding implementations. The first design is derived from the application family design for all five systems (Appendix B.1.1) and includes common interfaces at points of variability (Appendix B.2.1, B.3.1, B.4.1, B.5.1 and B.6.1). The second design is built using a traditional one-off approach that does not allow for variability (Appendix B.2.2, B.3.2, B.4.2, B.5.2 and B.6.2). The corresponding system
implementations of the five system pairs were done in Turbo Pascal. All source code for this case study can be found on the accompanying CD-ROM. To evaluate the performance of each version of each system we measured the average CPU time and the memory usage that is required to complete a single washcycle. To compensate for any inaccuracies of the system clock, each wash-cycle was repeated 2000000 times. We used a test harness to invoke each wash-cycle and to emulate Hardware I/O. The results for each system pair provided a measured figure for overhead for a given amount of variability.
7.2.2 Main/Subroutine Results
Table 7.1 shows the results for each of the system pairs. It shows the execution times (Pa) for 2000000 cycles of the five systems built from an application family and the corresponding execution times (Ps) for the same five systems built using a one-off approach. Table 7.1 details the execution time overhead (Pa Ps) per call to a common interface. Biasing Pa Ps by the total number of calls to a common interface
(C Vcalls) provides a figure for the execution time overhead Oexec per points of variability for Systems 1 to 5. We calculate Oexec using Equation 6.1.
Points of variability 2 (Minimum) 4 (Intermediate) 4 (Duplicate) 7 (Intermediate) 10 (Maximum) C Vcalls 2200000

System 5

Pa 2.53 s 4.82 s 5.08 s 8.47 s 12.61 s
Ps 2.20 s 3.84 s 4.39 s 7.08 s 10.49 s
Pa - Ps 0.33 s 0.98 s 0.69 s 1.39 s 2.12 s
Oexec 0.000000165 s 0.000000390 s 0.000000344 s 0.000000697 s 0.000000965 s
Table 7.1: Execution time overhead Oexec for Main/Subroutine case study Figure 7.2 shows a plot of execution time overhead Oexec against number of points of variability for a single test-cycle of each system. By observation the graph seems linear, hence we used linear regression to derive an equation for the graph. The residual error between the fitted equation and the plotted points is 0.0075. A t-test confirms that the measurements for execution time overhead for the Main/Subroutine experiments have a probability p greater than 99.9% of being representative and not due to random variance. (Appendix G.1).

Point on earth d2 S2

Figure 7.4: Example of the principle of global positioning A combination of distances to four satellites combined with the known locations of the four satellites allows us to pinpoint a position in space. Figure 7.4 shows a simplified two-dimensional example where a minimum of three satellites are required to calculate a position on earth (in three-dimensions, four satellites are required). In Figure 7.4, d1, d2 and d3 denote the distances from each satellite (S1, S2 and S3) to our location on earth. Triangulating the distances d1, d2 and d3 provides a point of intersection, which is our relative position to the satellites. Combining the relative position with the exact locations of each satellite allows us to calculate a location on Earth.
Our case study focuses on the algorithms to model satellite positions at any given point in time. We have constructed an MRAM application family model of GPS and GLONASS modelling algorithms. The application family model is based on
summaries of GPS and GLONASS presented in [7.4] and [7.5], and can be found in Appendix C.1. The points of variability that we have identified include:
The algorithms shall model the positions of GPS and/or GLONASS satellite constellations multiple adaptor discriminant.
A satellite position shall be passed to a GPS device as an orbital phase rotation, or as a vector co-ordinate single adaptor discriminant.
A satellite position shall be calculated with respect to a viewpoint in space or an orthogonal view from earth single adaptor discriminant.
The four nearest satellites to a known position on earth shall be flagged. The nearer a satellite is, the better the signal will be optional discriminant.
Orbits, satellite identifiers and earth shall be displayed alongside each satellite multiple adaptor discriminant.
Up to seven landmarks may be displayed on earth multiple adaptor discriminant. Appendix C.1.1 details an object-oriented application family design that realises
the application family model in Appendix C.1, where the application family design is modelled using UML [7.6] (design notation summarised in Appendix A.2).
7.3.1 Object-Oriented Experiments
We have derived five requirements specifications from the application family model for five different GPS and GLONASS modelling systems. Each of the five system specifications incorporates a different amount of variability.
System 1 calculates the orbit phase of the GPS satellite constellations at a given point in time, and the results are passed to the receiver. It incorporates two points of variability. (Appendix C.2).
System 2 displays the GPS and GLONASS satellites on the receivers LCD using an orthogonal viewpoint on earth, and it highlights the four closest satellites. It incorporates four points of variability. (Appendix C.3).

System 3 displays the GLONASS satellites from a viewpoint in space. The three GLONASS orbits and each satellites identifier are drawn. It incorporates four points of variability. (Appendix C.4).
System 4 uses the receivers LCD to model the GPS and GLONASS satellites in an orbit around earth. For reference it also displays three landmarks on earth London, Sydney and Rio de Janeiro. It incorporates seven points of variability. (Appendix C.5).
System 5 models just the GPS constellation. It displays the six orbits, the satellite identifiers and seven landmarks on earth. For each landmark the optimum four GPS satellites are highlighted. variability. (Appendix C.6). Two designs were constructed for each of the five system specifications. The first This system incorporates eight points of
design is derived from the application family design (Appendix C.1.1) and includes common interfaces at all the points of variability (Appendix C.2.1, C.3.1, C.4.1, C.5.1
and C.6.1). The second design is built using a traditional one-off approach that does not allow for variability (Appendix B.2.2, C.3.2, C.4.2, C.5.2 and C.6.2). The
implementations of the five system pairs were done in C++, and the source code for the object-oriented experiments can be found on the accompanying CD-ROM. To evaluate the performance of each of the five systems we again measured the average CPU time and the memory usage that is required to model satellites over time. To minimise inaccuracies due to the lack of precision of the system clock, each test was repeated 2880 times. A test harness was used to invoke each modellingcycle and to emulate Hardware I/O. The results for each system pair provided a measured figure for overhead for a given amount of variability.
7.3.2 Object-Oriented Results
Table 7.3 shows the measured results from the object-oriented case study. It details the execution time overhead Oexec for Systems 1 to 5. We calculate Oexec using Equation 6.1.

Points of variability 2

(Minimum)
Pa 31.129 s 123.736 s 127.320 s 604.570 s 725.130 s
Ps 31.114 s 123.707 s 127.081 s 604.478 s 724.661 s
Pa - Ps 0.015 s 0.029 s 0.239 s 0.092 s 0.469 s

C Vcalls 24480 5348.6 25560
Oexec 0.000005208 s 0.000010069 s 0.000009763 s 0.000017201 s 0.000018349 s
4 (Intermediate) 4 (Duplicate) 7 (Intermediate) 8 (Maximum)
Table 7.3: Execution time overhead Oexec for ObjectOriented case study Figure 7.5 plots execution time overhead Oexec against the number of points of variability. Through observation we assumed a linear relationship and used a linear regression to fit an equation to the measurements. A residual error of 0.0106 suggests that there is a strong correlation between the measured points and the equation. A t-
test shows that there is a probability p of greater than 99.9% that the measurements for execution time overhead in our object-oriented case study are not due to random variance. (Appendix G.2).

2.50E-05 s

2.00E-05 s

R2 = 0.0106

1.50E-05 s

1.00E-05 s

5.00E-06 s t-stat = 51.37 Degree of freedom = 3 p = 99.9% 0.00E+00 s Points of variability
Figure 7.5: Plot of execution time overhead Oexec against points of variability for Object-Oriented case study Table 7.4 shows the memory space measurements for the object-oriented experiments. It itemises the memory overhead Omem for systems with 2, 4 (2), 7 and 8 points of variability. We use Equation 6.2 to calculate Omem.
Points of variability 2 (Minimum) 4 (Intermediate) 4 (Duplicate) 7 (Intermediate) 8 (Maximum)
Ma 835072 Bytes 836626 Bytes 864256 Bytes 871936 Bytes 845312 Bytes
Ms 834714 Bytes 835895 Bytes 863383 Bytes 870656 Bytes 843878 Bytes
OMem 358 Bytes 731 Bytes 873 Bytes 1280 Bytes 1434 Bytes
Table 7.4: Memory space overhead Omem for ObjectOriented case study Figure 7.6 plots Omem against the number of points of variability. A linear
regression was used to estimate and plot an adequate equation. The residual error is 0.0271, and the results of a t-test show a probability p of greater than 99.9% that the figures of our measurements are not due to chance. (Appendix G.2).
1800 Bytes 1600 Bytes 1400 Bytes 1200 Bytes Memory overhead 1000 Bytes 800 Bytes 600 Bytes 400 Bytes 200 Bytes 0 Bytes Points of variability t-stat = 31.73 Degree of freedom = 3 p = 99.9% R2 = 0.0271
Figure 7.6: Plot of memory overhead Omem against points of variability for Object-Oriented case study
7.4 Case Study 3: Pipe and Filter
The experiments for the Pipe and Filter case study are taken from automated process control. Our experiments are derived from a family of systems that
simultaneously regulate liquid levels in two large storage-tanks. Figure 7.7 shows the physical layout of our application family of liquid regulators. The tanks are

controlled by a closed feedback loop using an on/off control algorithm, and the controller software is responsible for maintaining a constant set point in the tanks. Sensors measure the actual liquid levels and transmit them to the software. If the measured level is below the set point the respective valves are opened until the tank is full again. The states of the tanks and of the valves are logged for status and fault analysis.
Set point Valve status Valve status Tank 2 Tank 1

Set point

Sensor Liquid level
Controller software Liquid level New set point values System status

Sensor

User terminal
Backup media (hard disk / printer)
Figure 7.7: System layout for Pipe and Filter case study
We have constructed an MRAM application family model for controller software of liquid regulating systems. The application family model is based on automated process control examples in [7.7] and [7.8], and can be found in Appendix D.1. Our application family model of controller software notes 10 points of variability, including:
Sensor values shall be acquired through a serial port or a parallel port for Tank 1 and/or Tank 2 single adaptor discriminant.
The sensor readings from Tank 1 and/or Tank 2 shall be converted from liquid weight to liquid volume single adaptor discriminant.
The set point for either of the tanks shall be adjustable through a remote user terminal optional discriminant.
For either of the tanks, 10 liquid level and valve status readings shall be averaged before logging optional discriminant.
Tanks levels and valve states shall be stored to hard disk and/or written to printer multiple adaptor discriminant.
A redundant secondary backup device shall be added optional discriminant. From the specifications in the application family model we constructed an
application family design for our controller software (See Appendix D.1.1). The design uses a Pipe and Filter notation described in Shaw et al [7.9].
7.4.1 Pipe and Filter Experiments
Five requirements specifications were derived from our application family model for five controller systems that simultaneously regulate liquid levels in two tanks.

Again, each system derived from the application family model incorporates different amounts of variability. These are:
System 1 controls both tanks through a serial port connection; it requires no extra data processing. Acquired values are logged to hard disk. It incorporates three points of variability. (Appendix D.2).
System 2 controls Tank 1 through a serial port and Tank 2 through a parallel port. 10 measurements from Tank 1 are averaged before logging. Acquired values are logged to hard disk and a backup device. It incorporates five points of variability. (Appendix D.3).
System 3 is required to control Tank 1 through a parallel port and Tank 2 through a serial connection. Both tanks have an adjustable set point. Acquired values from Tank 1 are converted to measures of volume. 10 measurements from Tank 2 are averaged before logging. Acquired data is logged to hard disk, printer and a secondary backup device. This system incorporates eight points of variability. (Appendix D.4).
System 4 controls Tank 1 through a serial port and Tank 2 through a parallel port. Readings from both tanks are converted to measures of volume and average 10 readings before logging the measurements. Tank 2 has an adjustable set point. The acquired values are sent to a printer. It also incorporates eight points of variability. (Appendix D.5).
System 5 controls both tanks through a serial port connection. Readings from both tanks are converted to measures of volume. Tank 1 and Tank 2 both have adjustable set points. For each tank, 10 readings are averaged before they are logged. Readings are logged to hard disk, printer and a secondary backup device. It incorporates 10 points of variability. (Appendix D.6).
Two designs with corresponding implementations were created for each of the five system specifications. The first design is derived from the application family design (Appendix D.1.1) and includes common interfaces at all the points of variability (Appendix D.2.1, D.3.1, D.4.1, D.5.1 and D.6.1). The second design is built using a traditional one-off approach that does not allow for variability (Appendix D.2.2, D.3.2, D.4.2, D.5.2 and D.6.2). The 10 implementations for the five system pairs were programmed in C, and the source code for this experiment can be found on the accompanying CD-ROM. To evaluate the performance of each system we measured the average CPU time and the memory usage. To compensate for inaccuracies of the system clock, each control cycle was repeated 10000 times. A test-harness was used to invoke each control cycle and to emulate serial, parallel, hard disk and printer I/O. The results for each system pair provided a measured figure for execution time and memory space overhead for a given amount of variability.

7.4.2 Pipe and Filter Results
Table 7.5 details execution time overhead Oexec for Systems 1 to 5. calculated using Equation 6.1.
Points of variability 3 (Minimum) 5 (Intermediate) 8 (Intermediate) 8 (Duplicate) 10 (Maximum) C Vcalls 13333.8400

Oexec is

Pa 12.24 s 14.83 s 22.35 s 17.46 s 19.88 s
Ps 10.54 s 11.59 s 16.21 s 12.03 s 13.19 s
Pa - Ps 1.70 s 3.24 s 6.14 s 5.43 s 6.69 s
Oexec 0.0001275 s 0.000311538 s 0.000599024 s 0.000603333 s 0.000796429 s
Table 7.5: Execution time overhead Oexec for Pipe and Filter case study
Figure 7.8 shows a plot of the execution time overhead measurements in Table 7.5 against the number of points of variability for a single controlling cycle. This time the equation is not linear. We used a least squares fit to estimate a quadratic equation relating the points of variability to the execution time overhead. A plot of the
residuals (Appendix G.3) indicates that the quadratic equation is probably an ample fit. The residual error between the quadratic equation and the plotted points is 0.0044.
0.0010 s 0.0009 s Execution time overhead per cycle 0.0008 s 0.0007 s 0.0006 s 0.0005 s 0.0004 s 0.0003 s 0.0002 s 0.0001 s 0s Points of variability 12 t-stat = 24.96 Degree of freedom = 3 p = 99.9% R2 = 0.0044
Figure 7.8: Plot of execution time overhead Oexec against points of variability for Pipe and Filter case study Table 7.6 shows the memory overhead results for the Pipe and Filter case study. It details the memory space overhead Omem for systems with 3, 5, 8 (2) and 10 points of variability. Equation 6.2 from chapter 6 was used to calculate Omem.
Points of variability 3 (Minimum) 5 (Intermediate) 8 (Intermediate) 8 (Duplicate) 10 (Maximum)
Ma 352256 Bytes 405504 Bytes 499712 Bytes 487424 Bytes 552960 Bytes
Ms 311296 Bytes 339968 Bytes 393216 Bytes 380928 Bytes 417792 Bytes
OMem 40960 Bytes 65536 Bytes 106496 Bytes 106496 Bytes 135168 Bytes
Table 7.6: Memory space overhead Omem for Pipe and Filter case study Figure 7.9 shows a plot of the memory space overhead against number of points of variability for each of the liquid level controlling systems. A linear regression was used to estimate the best fitting equation for the plot. The residual error between the equation and the plotted points is 0.0009. (Appendix G.3).
160000 Bytes 140000 Bytes 120000 Bytes Memory overhead 100000 Bytes 80000 Bytes 60000 Bytes 40000 Bytes 20000 Bytes 0 Bytes Points of variability 12 t-stat = 193.84 Degree of freedom = 3 p = 99.9% R2 = 0.0009
Figure 7.9: Plot of memory overhead Omem against points of variability for Pipe and Filter case study

7.5 Case Study 4: Event-Based / Implicit Invocation
Our fourth case study is taken from an application family of onboard instrument control unit (ICU) software in satellites. In our application family the primary
requirements of the ICU software are to: control and monitor onboard instruments; to verify and execute macro-commands from Earth; to generate and report real-time telemetry to Earth; to handle bus interface protocols; and to manage anomalies. Figure 7.10 demonstrates typical interconnections between an ICU and its onboard instruments. The ICU software controls and monitors the onboard instruments and passes telemetry and status information to other systems through the data bus. It controls the onboard instruments in response to macro-commands and each instruments internal state.
Onboard Data Handling Bus
Macro-commands from Earth Telemetry to Earth

Instrument Control Unit

Control Telemetry & state

Onboard Instrument

ICU Software Telemetry & state Control Onboard Instrument
Figure 7.10: Conceptual layout of on-board instrument control unit Onboard instruments can have up to five operating modes: standby; initialising; stabilising; measuring; and shutdown/refuse.
In Standby mode onboard instruments are idle. The onboard instruments do not acquire any telemetry; they just poll for a mode-switch macro-command to the instrument control unit.
Initialising mode is used to prepare onboard instruments for measuring. Status information may be acquired during initialisation. Examples of onboard
instruments that may require and initialise state include heated or cooled instruments, which have a set working temperature.
A Stabilising mode is sometimes required to adjust the internal calibration of onboard instruments. Instruments may transmit their status. Again, heated or cooled instruments may have a stabilising mode that adjusts their temperature back to the required set point.
The Measuring mode is an instruments operating mode. In measuring mode onboard instruments will transmit their status and any required telemetry.
Shutdown/Refuse mode is used in the event of an anomaly.

The onboard

instruments are switched off; any mode switch instructions other than to standby are ignored. There are two ways in which an instrument may change its operating mode. A macro-command from earth may request a change of mode or the instrument itself may request a different mode. The ICU software must respond to either type of event and switch the onboard instrument appropriately. We have constructed an application family model for the part of the ICU software that is responsible for controlling mode switching for a single onboard instrument. The application family model is based on control software for a Doppler Orbitograph
and Radio-positioning instrument (DORIS) [7.10]2, a Microwave Radiometer (MWR) [7.10]2, and a Radar Altimeter (RA-2) [7.11]2 that are all part of the ENVISAT1 payload, and is detailed in Appendix E.1. Our application family model of ICU software notes 30 points of variability, including:

Optional macro-commands to switch the onboard instrument into the required modes. Note that omitting all events that switch the instrument to an undesired mode will exclude that mode.
The instrument shall have optional internal events that request it to be switched into a new mode.
Macro-commands and internal instrument events shall change the system mode and/or the state of the internal instruments multiple adaptor discriminant.
An optional RESET macro-command shall restart instruments that have been shut down. An application family design was built to realise the specifications in our
application family model of onboard instrument control unit software (See Appendix E.1.1). The designs are Harel state-transition diagrams [7.12] (design notations are noted in Appendix A.5).
7.5.1 Event-Based / Implicit Invocation Experiments
Five requirement specifications were derived from our application family model for five different instrument control units. Each specification incorporates a different amount of variability.
Although our specifications for a family of ICU software are based on specifications taken from the European Space Agency (ESA) documentation, our solutions are completely independent of ESA. Any resemblance to their actual products is coincidental.
System 1 can only switch its instrument from standby to measuring. incorporates two points of variability. (Appendix E.2).
System 2 can switch its instrument from standby to initialising and back, and from initialising to measuring. It also responds to shutdown and reset events and incorporates 10 points of variability. (Appendix E.3).
System 3 can switch its instrument from standby to stabilising and back, from stabilising to measuring and back, and from measuring to standby. It also
responds to the instruments internal states. This system incorporates 12 points of variability. (Appendix E.4).
System 4 can switch from standby to initialising, from initialising to stabilising and back, and from stabilising to measuring and back. From any mode it is able to switch back to standby or shutdown. It incorporates 20 points of variability. (Appendix E.5).
System 5 can switch from standby, initialising, stabilising and measuring to any state. It responds to the instruments internal states, to shutdown and to reset events and incorporates all 30 points of variability. (Appendix E.6). For each of the five system specifications we constructed two designs, each with a
corresponding implementation.
The first design is derived from the application
family design (Appendix E.1.1) and includes common interfaces at all the points of variability (Appendix E.2.1, E.3.1, E.4.1, E.5.1 and E.6.1). The second design is built using a traditional one-off approach that does not allow for variability (Appendix E.2.2, E.3.2, E.4.2, E.5.2 and E.6.2). The corresponding system implementations of the five system pairs were done in Ada95. All source code for this case study can be found on the accompanying CD-ROM.

7.6.2 Repository Results

Table 7.9 shows the measured results for the Repository case studies. It details the execution time overhead Oexec for Systems 1 to 5. We calculate Oexec using Equation 6.1.
Points of variability 3 (Minimum) 4 (Intermediate) 6 (Intermediate) 6 (Duplicate) 7 (Maximum) C Vcalls 10000
Pa 381.85 s 382.28 s 626.59 s 634.50 s 771.59 s
Ps 238.48 s 192.57 s 336.75 s 332.36 s 421.17 s
Pa - Ps 143.37 s 189.71 s 289.84 s 302.14 s 350.42 s
Oexec 0.014337 s 0.018971 s 0.028984 s 0.030214 s 0.035042 s
Table 7.9: Execution time overhead Oexec for Repository case study Figure 7.14 shows a plot of execution time overhead Oexec against the number of points of variability for a single image processing cycle. A linear regression was used to estimate the best fitting equation. The residual error between the equation and the plotted points is 0.0062. (Appendix G.5).
0.04 s 0.035 s Execution time overhead per cycle 0.03 s 0.025 s 0.02 s 0.015 s 0.01 s 0.005 s 0s 4 Points of variability t-stat = 88.62 Degree of freedom = 3 p = 99.9%

R2 = 0.0062

Figure 7.14: Plot of execution time overhead Oexec against points of variability for Repository case study Table 7.10 details the measured memory space overhead Omem for systems with 3, 4, 6 (2) and 7 points of variability. Omem is calculated using Equation 6.2.
Points of variability 3 (Minimum) 4 (Intermediate) 6 (Intermediate) 6 (Duplicate) 7 (Maximum)
Ma 2187264 Bytes 2486272 Bytes 3092480 Bytes 3112960 Bytes 3420160 Bytes
Ms 1884160 Bytes 2082960 Bytes 2494464 Bytes 2510848 Bytes 2716456 Bytes
OMem 303104 Bytes 403312 Bytes 598016 Bytes 602112 Bytes 703704 Bytes
Table 7.10: Memory space overhead Omem for Repository case study Figure 7.15 shows a plot of memory space overhead Omem against number of points of variability for our image processing system examples. Again, a linear regression
was used to estimate an adequate equation for the graph. The residual error between the equation and the plotted points is 0.0002. (Appendix G.5).
800000 Bytes 700000 Bytes R2 = 0.Bytes Memory overhead 500000 Bytes 400000 Bytes 300000 Bytes 200000 Bytes 100000 Bytes 0 Bytes 4 Points of variability t-stat = 474.59 Degree of freedom = 3 p = 99.9%
Figure 7.15: Plot of memory overhead Omem against points of variability for Repository case study

7.7 Summary

In this chapter we detailed the experiments that we used to help evaluate our thesis. We measured sets of execution time and memory space overhead for five case studies, each case study used a different common interface approach based on a different architectural style. Chapter 8 will discuss our results.

7.8 References

[7.1] Zanussi Washer-Dryer ZJD 125: Instruction booklet. Zanussi Limited, Zanussi House, Hambridge Road, Newbury, Berkshire, UK. Ref: 12498.6341.

[7.2] [7.3] [7.4] [7.5]

Zanussi Washer-Dryer WJS 1397 W: Instruction booklet. Zanussi Limited, Zanussi House, Hambridge Road, Newbury, Berkshire, UK. Ref: 12497.6391. E. Yourdon. Modern Structured Analysis. Prentice Hall, Englewood Cliffs, New Jersey, USA, 1989. ISBN 0-13-598624-9. B. Hofmann-Wellenhof, H. Lichtenegger, J. Collins. GPS Theory and Practices. Springer-Verlag, Vienna, Austria, 1997. ISBN 3-21-182839-7. A. Leick. GPS Satellite Surveying. Second Edition. John Wiley and Sons Inc., 605 Third Avenue, New York, NY 10158-0012, USA, 1995. ISBN 0-47130626-6. G. Booch, J. Rumbaugh. Unified Method for Object-Oriented Development. Technical Document. Rational Software Corporation, Santa Clara, California 95051-0951, USA. http://www.rational.com T. Hgglund. Process Control in Practice. Chartwell-Bratt Ltd., Old Orchard, Bickley Road, Bromley, Kent BR1 2NE, UK, 1991. ISBN 0-86238-294-7. C. A. Smith, A. B. Corripio. Principles and Practices of Automated Process Control. John Wiley and Sons Inc., 605 Third Avenue, New York, NY 101580012, USA, 1985. ISBN0-471-61633-8. M.Shaw, D. Garlan. Software Architecture, Perspectives on an Emerging Discipline. Prentice Hall, Upper Saddle River, New Jersey, USA, 1996, ISBN 0-13-182957-2.

[7.7] [7.8]

[7.10] D. S. Kenyon. DORIS/MWR ICU Software Requirements Document. Document Number PO-SR-RHE-IC-0001. Rhea Group, Lige, Belgium, 1996. [7.11] M. Canevari. RA-2 ICU-SW Requirements Specification. Document Number PO-RS-ALS-RA-0022. Alenia Spazio S.p.A., Roma, Italy, 1994 [7.12] D. Harel. Statecharts: A Visual Formalism For Complex Systems. 8th Conference on Science of Computer Programming, Elsevier, Holland, 1987, Pages 231-274. [7.13] R. C. Gonzalez, R. E. Woods. Digital Image Processing. Addison-Wesley, Reading, Massachusetts, USA, 1992, ISBN 0-201-50803-6. [7.14] W. Niblack. An Introduction to Digital Image Processing. 2nd Edition, Prentice Hall, Upper Saddle River, New Jersey, USA, 1986, ISBN 0-13480674-3.

Abstract

In seeking to gain a competitive edge, companies are searching for alternative methods for developing computer-based systems more effectively and efficiently. Application family engineering is seen as one potential solution. A principal idea of application family engineering is to identify commonalities and variability among systems of a family, into analysis, design and code assets. New systems can be generated from these assets by filtering out requirements, design and code solutions that do not trace to the particular needs of the new system. The embedded systems industry has been reluctant to embrace application family engineering and other reuse methods, because of a concern that application family assets include provisions for variability that may bear an unpredictable execution time and memory space overhead. In environments where time and space are in short supply, reuse (and maintenance) may be undesirable. However, there is little empirical evidence to support this concern. In this work we investigate the behaviour of the potential time and space overhead incurred by one design mechanism for managing variability in application family designs: common interfaces. Our approach is case study based and compares the performances of systems with one-off designs with no variability to the same systems
having application family designs with variability. Five common interface techniques for handling variability are examined, based on the components of five prevalent architectural styles, including Object-Orientation, Main/Subroutine, Event-Based, Pipe and Filter, and Repository architectural styles. For each architectural style we selected a case study application family that may typically be designed using that style. Our results show that all five architectural styles exhibit a clear correlation between execution time and memory space overhead, and the amount of variability. Our data implies that although a trade-off between reuse and performance may exist, it can be predictable and possibly even quantified. The implication that overhead can be predicted and possibly quantified may help decide the economic viability of reusing application family assets in an embedded environment.

CHAPTER 1

Introduction

1.1 Introduction

Companies are often unable to develop system solutions effectively and efficiently enough to meet demand. To tackle this problem, one software development approach is application family engineering. Examples of such families include mobile phones, pension plans, and satellite instrument control units. A product of application family engineering is an application family model, comprising of a set of reusable assets for a family of applications. It identifies commonality and points of variability of
existing and future systems of that family. New systems emerge from the interaction of two activities: application family engineering to create reusable assets and single system engineering to build single systems using those assets (Mannion et al [1.1], [1.2]). Embedded software systems are found in a number of applications including aircraft flight control, reactor safety systems, medical electronic devices, washing machines, and microwave ovens. They are characterised by having to operate within stringent constraints regarding physical space, memory space, safety, and timing. Under such constraints hardware and software must be compact and well designed.

While similar problems may exist with safety constraints and their applicability to varying components in an application family, this is beyond the scope of this work.
Evidence that our hypothesis holds true would imply the following:
The amount of potential overhead can be predicted and even quantified. A one-off single system, or parts thereof, with real-time and memory constraints may no longer be able to meet constraints if reengineered as application family design and code assets. The implication that overhead can be predicted and possibly quantified may help decide the economic viability of a reengineering process.
Existing real-time and memory constraints may no longer be valid if an application family design and implementation is evolved to include new variability. The implication that overhead can be predicted and possibly quantified may help decide the economic viability of evolving an application family. We use an experimental approach to support our claim. The results from our
experiments will aid system engineers to determine situations where constraints may be breached. Our work may help inform the trade-off decision as to whether to build a new component that meets constraints, or to reuse an old one. There is some evidence [1.11] that suggests that execution times will vary if different common interface approaches are used to realise application family variability. We have assumed here that any potential overhead that is associated with common interfaces will differ with platform, architectural style, design method and programming language. Our experiments investigate execution time and memory space overhead for five different common interface methods (grouped by Shaw et al [1.12]). We benchmark two systems with the same specification: a one-off single-system implementation, and an application family counterpart that accounts for variability. Using comparisons of different case study pairs per common interface method, we
show that there is a high probability that overhead is correlated to the amount of implemented variability.

1.4 Thesis Structure

Chapter 2 summarises the current state of software reuse, available reuse processes and methods. It also introduces application family engineering.
Chapter 3 introduces the MRAM application family engineering method that we are basing the variability notation in our experiments on.
Chapter 4 looks at application family design issues and guidelines that we must consider for our case studies.
Chapter 5 characterises embedded systems. It singles out how they vary from other types of systems. systems. We describe issues concerning reuse of embedded
Chapter 6 describes our experiment and evaluation approach. individual common interface methods that we scrutinise.

It details the

Chapter 7 introduces our case studies and presents their individual results. Chapter 8 provides some discussion and our overall conclusions.

[2.45] S. G. Cohen, J. L. Stanley Jr., A. S. Peterson, R. W. Krut Jr. Application of Feature-Oriented Domain Analysis to the Army Movement Control Domain. Special Report, Software Engineering Institute, Pittsburgh, USA, June 1992. CMU/SEI-91-TR-28. [2.46] M. Simos. Organisation Domain Modelling (ODM) Guidebook Version 1.0. Technical Report: STARS-VC-A023/011/00, Lockhead Martin Tactical Defence Systems, Manassa, VA, USA, March 1995. [2.47] M.Shaw, D. Garlan. Software Architecture, Perspectives on an Emerging Discipline. Prentice Hall, Upper Saddle River, New Jersey, USA, 1996, ISBN 0-13-182957-2. [2.48] M. Simos. Organisation Domain Modelling (ODM) Guidebook Version 2.0. Technical Report: STARS-VC-A023/001/00, Lockhead Martin Tactical Defence Systems, Manassa, VA, USA, June 1996. [2.49] D. Garlan, R. Allen, J. Ockerbloom. Architectural Mismatch: Why Reuse Is So Hard. IEEE Software, Volume 12, Number 6, Pages 17-26, November 1995. [2.50] M. Mannion, O. Lewis, H. Kaindl, G. Montroni, J. Wheadon. Representing Requirements on Generic Software in an Application Family Model. 6th IEEE International Conference on Software Reuse (ICSR 6), Vienna, Austria, Pages 153-169, June 2000. ISBN 3-540-67696-1. [2.51] M. Griss, J. Favaro, M. dAlessandro. Integrating Feature Modelling with the RSEB. Proceesings of the Fifth IEEE International Conference on Software Reuse (ICSR5), Vancouver, Canada, June 1998, Pages 76-85. [2.52] M. Mannion, B. Keepence, H. Kaindl, J. Wheadon. Reusing Single System Requirements for Application Family Requirements. Proceedings of the 21st International Conference on Software Engineering (ICSE21), Los Angeles, California, USA, Pages 453-462, May 1999. ISBN 1-58113-074-0. [2.53] B. Keepence, M. Mannion, C. D. McCausland. Pattern Based Transformation of Domain Features. IEEE Symposium on Engineering of Computer-Based Systems, Friedrichshafen, Germany, March 1996. [2.54] T. P. Kelly, W. Lam, B. R. Whittle. Diary of a Domain Analyst: A Domain Analysis Case-Study from Avionics. Proceedings of International Federation of Information Processing Workgroups 8.1 and 13.2 Conference on Domain Knowledge for Interactive System Design, Geneva, Switzerland, May 1996.
[2.55] J. M. DeBaud, O. Flege, P. Knauber. PuLSEDSSA: A Method for the Development of Software Reference Architectures. Proceedings of the 3rd International Software Architecture Workshop, Orlando, Florida, USA, Pages 25-28, November 1998. [2.56] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, J. M. DeBaud. PuLSE: A Methodology to Develop Software Product Lines. Proceedings of the 5th ACM SIGSOFT Symposium on Software Reusability (SSR99), Los Angeles, California, USA, Pages 122-131, May 1999. [2.57] J. OConner. Reuse in Command-and-Control Systems. IEEE Software, Volume 11, Number 5, Pages 70-79, September 1994. [2.58] Software Technology for Adaptable Reliable Systems (STARS). STARS Conceptual Framework for Reuse Processes (CFRP), Volume I: Definition, Version 3.0. Unisys STARS Technical Report STARS-VC-A018/001/00, Advanced Research Projects Agency, STARS Technology Center, 801 N. Randolph St. Suite 400, Arlington VA 22203, USA, October 1993. [2.59] M. Ezran, M. Morisio, and C. Tully. Diversity in Reuse Processes. IEEE Software, Volume 17, Number 4, Pages 56-63, July/August 2000. [2.60] A. Mili, S. M. Yacoub. A Comprehensive Analysis of Domain Engineering Methods: A Controlled Case Study. 22nd International Conference on Software Engineering (ICSE22), Workshop on Software Product Lines: Economics, Architectures, and Implications, Limerick, Ireland, Pages 20-31, June 2000.

discriminant-based selection process to build single systems from an application family model. This can help ensure that conflicting requirements do not coexist in new systems. We use the MRAM discriminant-based selection process to specify all systems of our experiments. MRAM was used to generate an application family of spacecraft control operating systems at ESOC (Mannion et al [3.7]). To automate and support the management of the application family we developed a Tool for Requirements Authoring and Management (TRAM).
3.2 MRAM Application Family Model
The MRAM application family model depicts commonality and variability of requirements between systems in a family. Requirements in the application family model are structured hierarchically, following guidelines by Keepence et al [3.8]. The hierarchy of requirements is achieved by splitting the specific from the generic. It is often the case that a requirement contains generic and specific parts. Although such requirements are valid, they may reduce the level of reuse. Here is an example: REQ 1 A mobile phone shall support text messaging using SMS text messages and SMTP electronic mail messages. Text messaging systems for all mobile phones typically use SMS text messages, but e-mails, as a messaging system, are specific to mobile phones with WAP capabilities. Hence the requirement could be written as follows: REQ 1 A mobile phone shall support text messaging.
REQ 1.1 A mobile phone shall support text messaging using SMS text messages. REQ 1.2 A mobile phone shall support text messaging using SMTP electronic mail messages.
1.2 (Point of variability)
Figure 3.1: Example hierarchy attributed to splitting the specific from the generic The result is two directly reusable requirements (REQ 1 and REQ 1.1) and one point of variability (REQ 1.2) that can be structured hierarchically (see Figure 3.1).
The MRAM application family model represents commonalities and variability in the form of directly reusable requirements and variable requirements. Figure 3.1 shows how the generalisation forces the hierarchy into a tree structure where requirements have a parent-child relationship. The deeper the requirement is within the hierarchy, the more specific it is likely to be.

3.2.1 Discriminants

One technique for specifying variable requirements is to label those requirements as discriminants (Mannion et al [3.1]). A discriminant is any requirement that
differentiates between systems. These can take on one of three basic forms:
Single adaptor discriminant: A set of mutually exclusive requirements from which only one can be chosen in any system in the application family. For example, a mobile phone requires the network services of a telecommunications carrier, but it will only ever use one carrier at a time. specification this might be written as: REQ 2

[3.16] J. M. DeBaud, O. Flege, P. Knauber. PuLSEDSSA: A Method for the Development of Software Reference Architectures. Proceedings of the 3rd International Software Architecture Workshop, Orlando, Florida, USA, Pages 25-28, November 1998. [3.17] W. Tracz. Collected Overview Reports From the DSSA Project. Technical Report: Lockhead Martin Federal Systems, Owego, NY 13827-3998, USA, September 1995.

CHAPTER 4

Application Family Design
4.1 Application Family Design
Chapter 3 outlined application family analysis and the construction of single system specifications from an application family model (also see Chapter 2, Figure 2.2). This chapter discusses application family design and the construction of single system designs from an application family design. New system designs are engineered from relevant components of an application family design that implement the desired functionality of a system. There are many application family design methods, each of which use different mechanisms and techniques to incorporate, and manage, commonality and variability. This chapter introduces and discusses our preferred mechanism of designing variability using common interfaces. We show how common interfaces can use the discrimination mechanism of MRAM to depict points of variability in application family designs.
4.2 A Taxonomy of Mechanisms to Manage Variability
Cortese et al [4.1] present a taxonomy of five mainly object-oriented techniques and mechanisms for handling application family variability in application family designs and implementations. Their taxonomy is insufficient for our purposes as we investigate both object-oriented and non-object-oriented application family design approaches. By generalising their taxonomy, we can note five mechanisms to handle variability that are independent of object-orientation. While there may be more finetuned ways of defining this taxonomy; the following five categories cover the majority of mechanisms for dealing with application family commonality and variability.

4.2.1 Parameterisation

One category in the object-oriented taxonomy in [4.1] is Property-Based Customisation. Classes are customised by having them reveal a number of their properties. Figure 4.1 shows a class called Ringing Mechanism that is responsible for the ringing melody that a mobile phone makes on receiving a call. It exposes one property that can be customised RingType. Defining the value of the RingType property will define the melody that the mobile phone plays when a call is received.
Ringing Mechanism RingType : Enum Ring ( )
Figure 4.1: Example of a class that has customisable properties
We can generalise the property-based customisation technique to make it equally applicable to non-object-oriented design methods, and use a broader term to denote this type of mechanism Parameterisation. In the object-oriented approach, a class will behave differently depending on its properties. Cortese et al [4.1] use Java Beans as an example of components which can be customised by setting the appropriate parameter values the properties of the Java Bean. However, many design and code components (not just objects and

REQ 6.2.1 REQ 6.2.2 REQ 6.2.3 REQ 6.2.4 REQ 6.2.5
This same principle can be used to model requirement 6.2 in application family design. Figure 4.12 shows how qualitative variability can model quantitative variability; the alternative connection time limits are accessed through a common interface. The design uses process-flow diagrams according to Yourdon [4.21] and is based on our single adaptor pattern from Figure 4.9 to model qualitative variability.
CI Connect n Selection made at build-time
Connect within 1 Second n.1
Connect within 2 Seconds n.2
Connect within 2.7 Seconds n.3
Connect within 3 Seconds n.4
Connect within 3.1 Seconds n.5
Figure 4.12: Example design of quantitative variability of requirement 6.2 using a common interface Using common interfaces to denote quantitative variability in terms of qualitative variability can help maintain consistency throughout an application family design as all points of variability in the design use the same mechanism.
4.5 Reference Architectures and Application Family Frameworks
Components in an application family design are often presented as groups or subcollections with a public, common interface. Some common interface approaches have an underlying framework (Fayad et al [4.2]) or a reference architecture (DSSA [4.10], PuLSE [4.18]), where the desired components, with the correct common interface, can plug into. Matsumoto et al [4.22] define a reference architecture as a core portion of all systems of a family, which represents common structure, functionality, nonfunctionality and variability. Reference architectures are often ad-hoc, high-level conceptual representations of an application family. Typically, common interfaces are defined at points of variability in the reference architecture. New systems are
composed by plugging the required components, chosen from lists of alternative components that conform to the common interface, into the reference architecture. Fayad et al [4.2] suggest that application family frameworks are often based on reference architectures. While reference architectures denote core components and application family variability at a conceptual level, a framework is less abstract and normally very code oriented. Application family frameworks represent a more
detailed design of core components for systems of a family. They are typically aimed at a specific design method or programming language.
Application family Single system Core Single system

Single system

Figure 4.13: Example application family scope and single systems within that scope that share a common core However, both reference architectures and application family frameworks assume that all systems in the application family share a large common core. We can
demonstrate this using a Venn diagram. Figure 4.13 illustrates the boundaries (the scope) of a family of applications; four systems of that family are shown. The grey area in Figure 4.13 demonstrates the core portion of all four systems: the reference architecture; or application family framework. The problems of having a central core, which is common to all systems within a family, are usually related to scoping and

[5.45] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Objectoriented Modelling and Design. Prentice-Hall International Editions, Englewood Cliffs, New Jersey, USA, Pages 25-26, 1991. ISBN 0-13-6300545. [5.46] D. S. Kenyon. DORIS/MWR ICU Software Requirements Document. Document Number PO-SR-RHE-IC-0001. Rhea Group, Lige, Belgium, 1996.

CHAPTER 6

Experiment Design

6.1 Introduction

This chapter describes the rationale and design of the experiments for which results are reported in Chapter 7. We will investigate the possible introduction of execution time and memory space overhead for a number of different common interface methods. It is not feasible to examine the performance of every possible common interface approach on every platform, using every architectural style, design method and programming language. We have chosen to examine the behaviour of five
application family design methods, based on five common architectural styles, each using a very different type of common interface at points of variability. We believe that grouping our experiments by different common architectural styles will provide a more representative account of the behaviour of potential overhead. A correlation between overhead and number of points of variability for all five styles would be a very strong indication that other common interface approaches correlate similarly. In Section 6.2 we introduce the five architectural styles on which we base the application family designs in our case studies. We will demonstrate examples of how our universal design patterns in Chapter 4 can be used with the components of each
design method. Later sections will detail our intended experiments and evaluation techniques.
6.2 Software Architectures
There is currently no universally accepted definition of software architecture. Typically an architecture describes a software systems structure as a decomposition into elements and their interconnections. The IEEE ECBS TC Architecture Working Groups definition of architecture reads [6.1]:
A systems essential, unifying structure defined in terms of components, connections and constraints along with the systems interaction with its environment.
6.2.1 Architectural Styles
The IEEE ECBS TC Architecture Working Groups definition of an architectural style is [6.1]:
The language, notation and structuring guidelines for representing system architectures. They provide specific analysis based on the formality of the system representation. An architectural style provides the formal building blocks of an architectural
design. There are a finite number of commonly referenced architectural styles. Many of these styles are based on common design and programming methods. For example, the Main/Subroutine style (Shaw et al [6.2]) is based on structured, functional design methods. Some architectural styles model systems at such an abstract level that their components are not easily mapped to components of a design or programming

differences an average value from multiple test-runs shall be taken for each experiment. Also, to ensure consistency, no compiler optimisations were used in any of our experiments as they influence both execution times and memory usage.
6.3.1.1 Measuring Execution Time Overhead
The equation we use to calculate the execution time overhead Oexec for a system pair with a given number of points of variability is Pa Ps C Vcalls

Oexec =

Equation 6.1
where Pa is the execution time (in seconds) of a system built from an application family over many test cycles. We define a test cycle as one complete execution of either system in the pair. Typically, many test cycles are required to eliminate any inaccuracies due to the differences in resolution of the unit of measurement and the system clock (see section 6.3.1). Ps denotes the average execution time (in seconds) for the same software built using a traditional single system approach over the same number of test cycles. Vcalls are the number of calls to a common interface per cycle. C is the number of test cycles. Pa Ps calculates the difference in total execution time between the two systems in every pair. This difference denotes the execution time overhead that is introduced by all common interfaces that are called in the application family solution (Pa) and are not present in the one-off solution (Ps).
It is unlikely that a system has the same number of common interface as it does points of variability. A common interface may be called from within a loop, or recursively. Hence, Pa Ps denotes the execution time overhead for a number of calls to a common interface for many test cycles. In line with our hypothesis, the division by (C Vcalls) will bias the calculation for execution time overhead to annul multiple calls to the same interface and multiple test cycles. Oexec is thus the execution time overhead introduced by a number of points of variability (and not common interfaces), for one test cycle. To demonstrate, consider an example single system that is built from an application family model and implements 10 points of variability. In each test cycle of the system, two common interfaces denoting two different points of variability are called twice, all other common interfaces are only called once (Vcalls = 12). The experiment runs over 100 test cycles (C = 100). The execution time for 100 test cycles and 12 calls to a common interface is 15.342 seconds (Pa). An equivalent onoff solution of the system executes 100 test cycles in 12.127 seconds (Ps). Hence, the overhead for 10 points of variability and one test cycle (one single execution) would be 2.68 milliseconds.

Ma 835072 Bytes 836626 Bytes 864256 Bytes 871936 Bytes 845312 Bytes
Ms 834714 Bytes 835895 Bytes 863383 Bytes 870656 Bytes 843878 Bytes
OMem 358 Bytes 731 Bytes 873 Bytes 1280 Bytes 1434 Bytes
Table 7.4: Memory space overhead Omem for ObjectOriented case study Figure 7.6 plots Omem against the number of points of variability. A linear
regression was used to estimate and plot an adequate equation. The residual error is 0.0271, and the results of a t-test show a probability p of greater than 99.9% that the figures of our measurements are not due to chance. (Appendix G.2).
1800 Bytes 1600 Bytes 1400 Bytes 1200 Bytes Memory overhead 1000 Bytes 800 Bytes 600 Bytes 400 Bytes 200 Bytes 0 Bytes Points of variability t-stat = 31.73 Degree of freedom = 3 p = 99.9% R2 = 0.0271
Figure 7.6: Plot of memory overhead Omem against points of variability for Object-Oriented case study
7.4 Case Study 3: Pipe and Filter
The experiments for the Pipe and Filter case study are taken from automated process control. Our experiments are derived from a family of systems that
simultaneously regulate liquid levels in two large storage-tanks. Figure 7.7 shows the physical layout of our application family of liquid regulators. The tanks are
controlled by a closed feedback loop using an on/off control algorithm, and the controller software is responsible for maintaining a constant set point in the tanks. Sensors measure the actual liquid levels and transmit them to the software. If the measured level is below the set point the respective valves are opened until the tank is full again. The states of the tanks and of the valves are logged for status and fault analysis.
Set point Valve status Valve status Tank 2 Tank 1

Set point

Sensor Liquid level
Controller software Liquid level New set point values System status

Sensor

User terminal
Backup media (hard disk / printer)
Figure 7.7: System layout for Pipe and Filter case study
We have constructed an MRAM application family model for controller software of liquid regulating systems. The application family model is based on automated process control examples in [7.7] and [7.8], and can be found in Appendix D.1. Our application family model of controller software notes 10 points of variability, including:
Sensor values shall be acquired through a serial port or a parallel port for Tank 1 and/or Tank 2 single adaptor discriminant.
The sensor readings from Tank 1 and/or Tank 2 shall be converted from liquid weight to liquid volume single adaptor discriminant.
The set point for either of the tanks shall be adjustable through a remote user terminal optional discriminant.

Figure 7.9: Plot of memory overhead Omem against points of variability for Pipe and Filter case study
7.5 Case Study 4: Event-Based / Implicit Invocation
Our fourth case study is taken from an application family of onboard instrument control unit (ICU) software in satellites. In our application family the primary
requirements of the ICU software are to: control and monitor onboard instruments; to verify and execute macro-commands from Earth; to generate and report real-time telemetry to Earth; to handle bus interface protocols; and to manage anomalies. Figure 7.10 demonstrates typical interconnections between an ICU and its onboard instruments. The ICU software controls and monitors the onboard instruments and passes telemetry and status information to other systems through the data bus. It controls the onboard instruments in response to macro-commands and each instruments internal state.
Onboard Data Handling Bus
Macro-commands from Earth Telemetry to Earth

Instrument Control Unit

Control Telemetry & state

Onboard Instrument

ICU Software Telemetry & state Control Onboard Instrument
Figure 7.10: Conceptual layout of on-board instrument control unit Onboard instruments can have up to five operating modes: standby; initialising; stabilising; measuring; and shutdown/refuse.
In Standby mode onboard instruments are idle. The onboard instruments do not acquire any telemetry; they just poll for a mode-switch macro-command to the instrument control unit.
Initialising mode is used to prepare onboard instruments for measuring. Status information may be acquired during initialisation. Examples of onboard
instruments that may require and initialise state include heated or cooled instruments, which have a set working temperature.
A Stabilising mode is sometimes required to adjust the internal calibration of onboard instruments. Instruments may transmit their status. Again, heated or cooled instruments may have a stabilising mode that adjusts their temperature back to the required set point.
The Measuring mode is an instruments operating mode. In measuring mode onboard instruments will transmit their status and any required telemetry.
Shutdown/Refuse mode is used in the event of an anomaly.

The onboard

1.2.1.4.3 1.2.1.5 1.2.1.5.1 OP 1.2.1.5.1.1 1.2.1.5.2 1.2.1.5.3 1.2.2 1.3 1.3.1 1.3.2 1.3.3 OP 1.3.3.1 1.3.4 1.4 SA 1.4.1 1.4.1.1 1.4.1.2 OP 1.4.1.2.1 1.4.1.3 1.4.2 1.4.2.1 1.4.2.2 OP 1.4.2.2.1 1.4.2.3 1.5 SA 1.5.1 1.5.1.1 OP 1.5.1.1.1 1.5.1.2 1.5.1.3 1.5.1.4 1.5.1.5 1.5.1.6 1.5.2 1.5.2.1 OP 1.5.2.1.1 1.5.2.2 1.5.2.3 1.5.2.4 1.5.2.5 1.5.2.2.1 SA
The drum shall spin at speed setting 3 for 90 time units. The water shall be heated to 95 C. Check the ECO buttons state. If the button is pressed, only heat the water to 60 C. The drum shall be filled with the heated water. The drum shall spin at speed setting 3 for 90 time units. Following the spin, the machine shall be drained. Rinse phase The drum shall be filled with cold water. The drum shall spin at speed setting 1 for 25 time units. Check the rinse-hold buttons state. Wait for rinse-hold button to be released. The machine shall be drained. Spin phase The spin phase shall be a short spin phase The drum shall spin at speed setting 30 for 65 time units. Check the reduced-spin buttons state If pressed, the drum shall only spin for 45 time units. Any excess water shall be drained. The spin phase shall be a long spin phase The drum shall spin at speed setting 30 for 120 time units. Check the reduced-spin buttons state If pressed, the drum shall only spin for 65 time units. Any excess water shall be drained. Tumble-dry phase The drying phase shall do a low-temperature dry. The dry indicator light shall be lit during the drying phase. The light shall be switched off after the drying phase. The machine shall be drained before the drying phase. The drum shall be heated to 80 C. The drum shall cycle at speed setting 2. The external timer shall control the duration of the drying phase. Any excess water shall be drained. The drying phase shall do a high-temperature dry. The dry indicator light shall be lit during the drying phase. The light shall be switched off after the drying phase. The machine shall be drained before the drying phase. The drum shall be heated to 100 C. The drum shall cycle at speed setting 2. The external timer shall control the duration of the drying phase. Any excess water shall be drained. The drums door shall be locked prior to any wash cycle The door shall be unlocked
Immediately after a cycle is complete. After a 2 minute delay
B.1.1 Application Family Design

Test Harness

CI WashCycle
Figure B.1: Context diagram

WashCycle 1.

Figure B.2: CI WashCycle (Context)
Req 1 MA DoorLock 1.1 CI Prewash 1.2 CI Wash 1.3 Req 1 MA Rinse 1.4 CI Spin 1.5 CI Dry 1.6 CI DoorUnlock 1.7 Req 1 MA Req 1 MA Req 1 MA
Figure B.3: WashCycle (1)

Req 1.1.1 SA

Figure B.4: CI Prewash (1.2)

Req 1.2.1 SA

Wash 30 1.3.1

Wash 40 1.3.2

Wash 50 1.3.3

Wash 60 1.3.4

Wash 95 1.3.5
Figure B.5: CI Wash (1.3)

Req 1.2.1.4.1 OP

1 Inst. as NormalPerspectiveEarthOrbitSatIDDrawer InstantiatedNormalPerspectiveEarthOrbitSatIDDrawer <InstantiatedEarthDrawerWithLandmarks> <NormalOrbitDrawer> <NormalSatelliteIDDrawer>
1 Inst. as EarthDrawerWithLandmarks InstantiatedEarthDrawerWithLandmarks <InstantiatedLandMarkDrawerWithGPSOPT >
1 Inst. as LandMarkDrawerWithGPSOPT InstantiatedLandMarkDrawerWithGPSOPT <InstantiatedLandMarkArray7> <NormalGPSOPTDrawer>
1 Inst. as LandMarkArray7 InstantiatedLandMarkArray7 <London> <NewYork> <Moscow> <Tokio> <Sydney> <Rio> <Delhi>
Figure C.51: Test Harness (Package)

C-xxvii

C.6.2 Single System 5 Design without Variability
uses Satellite ID Drawer uses Normal Drawer uses Earth Drawer uses Landmark Drawer uses GPS Opt Drawer uses Landmark Array uses Landmark Types uses Orbit Drawer
Figure C.52: Single system 5 package dependencies
Figure C.53: Test Harness (Package)

C-xxviii

PositionModeller TheOutput : OutputToLCDScreen TheConstellations : GPS CurrentTime : T ime ModelSatellites() SetCurrentT ime()
Figure C.54: Position Modeller (Package)
Figure C.55: Output Types (Package)
NormalPerspective TheDrawer : NormalPerspectiveEarthOrbitSatIDDrawer Draw( The Satellites, Time)
1 NormalPerspectiveEarthOrbitSatIDDrawer
Figure C.56: Perspective (Package)

C-xxix

NormalPerspectiveEarthOrbitSatIDDrawer TheEarth : EarthDrawerWithLandmarks TheOrbit : NormalOrbitDrawer SatID : NormalSatelliteIDDrawer Draw( The Satellites, Time)
Figure C.57: Normal Drawer (Package)
Figure C.58: Orbit Drawer (Package)
Figure C.59: Satellite ID Drawer (Package)
EarthDrawerWithLandmarks TheLandMarkDrawer : LandMarkDrawerWithGPSOPT Draw( The Satellites, Time)
1 LandMarkDrawerWithGPSOPT
Figure C.60: Earth Drawer (Package)
LandMarkDrawerWithGPSOPT TheLandMarkArray : LandMarkArray7 TheGPSOPTDrawer: NormalGPSOPTDrawer DrawFarLandmarks( The Satellites, Time) DrawNearLandmarks( The Satellites, T ime)

1 LandMarkArray7

1 NormalGPSOPTDrawer
Figure C.61: Landmark Drawer (Package)
LandMarkArray7 Landmark1 : London Landmark2 : NewYork Landmark3 : Sydney Landmark4 : Tokio Landmark5 : Rio Landmark6 : Delhi Landmark7: Moscow DrawFarLandmarks( TheSatellites, T ime) DrawNearLandmarks( TheSatellites, Time)

1 NewYork

1 Tokio

1 Delhi

5 OP 5.1 5.2 5.3 OP 6 SA 6.1 6.2
A border shall be added to the processed image. The border shall be 10 pixels wide for the left, right and bottom border. The top border shall have a width of 36 pixels. The image shall be time-stamped and labelled within its top border. After processing the final image shall be released for further processing. The image shall be stored to an internal drive for further analysis and processing by other sub-systems. The image shall be transmitted to the ground station.
F.1.1 Application Family Design
Spectrum Analysis Type 1 Spectrum Analysis Type 2 Add Map Outline

Merge Original Image

Add Long- and Latitudinal Lines

CI Merge Original Image

CI Add Cartographic info

Add Landmarks

Outline Clouds

CI Outline Clouds

Upload Image

CI Add Border

CI Add T ime and Label

Add Border

Add T ime and Label

Store to Internal Drive

Send to Ground Station
Figure F.1: Application family design
F.2 Single System 1 Requirements Specification
1 1.1 1.SA 2.1 2.1.1 2.1.2 2.1.MA 4.1 4.2 4.SA 6.1 The system shall pre-process weather satellite images before they are transmitted to the ground station for analysis. The system shall acquire a digital satellite photograph from the satellites onboard camera. Each image shall have a resolution of 373 x 523 with 256 colours. A colour spectrum analysis shall be performed on the image. The analysis shall identify cloud regions by their colour intensity: The initial image shall be smoothed to intensify large areas of clouds. The smoothed image shall have the number of colours reduced to 10 red, 1 green and 1 blue colour steps. The final image shall be negated. Further cartographic information shall be added. Map outlines of the specific landmasses shall be added. Longitudinal and latitudinal lines shall be added to the image. Major cities and landmarks shall be added to the image. After processing the final image shall be released for further processing. The image shall be stored to an internal drive for further analysis and processing by other sub-systems.
F.2.1 Single System 1 Design with Variability
Spectrum Analysis Type 1 Add Map Outline
Figure F.2: Single system 1 with points of variability
F.2.2 Single System 1 Design without Variability
Spectrum Analysis Type 1 Add Map Outline Add Long- and Latitudinal Lines
Figure F.3: Single system 1 without points of variability
F.3 Single System 2 Requirements Specification
1 1.1 1.SA 2.2 2.2.1 2.2.2 2.2.3 2.2.OP 4 MA 4.3 The system shall pre-process weather satellite images before they are transmitted to the ground station for analysis. The system shall acquire a digital satellite photograph from the satellites onboard camera. Each image shall have a resolution of 373 x 523 with 256 colours. A colour spectrum analysis shall be performed on the image. The analysis shall identify the most intense cloud regions on the image. The initial image shall be smoothed to intensify large areas of clouds. The smoothed image shall have the number of colours reduced to 10 red, 1 green and 1 blue colour steps. The image shall be negated. All except the darkest area shall be deleted. The original image shall be merged into the analysed image. Further cartographic information shall be added. Major cities and landmarks shall be added to the image.