4.3.1 Reference Architecture Concept
A Reference Architecture provides a standard template architectural solution for a particular domain. Reference architectures are used as a basis for the development of particular software system solutions that fit within the target domain. They are especially useful as an enabler for a software product-line approach as they provide a framework within which product line assets can be developed. Assets that are compatible with the reference architecture will necessarily be compatible with a product instance derived from that reference architecture.
“The reference architecture is capturing domain knowhow from the past and the vision of
the future to guide architecting of future systems” [33]
The purpose of the reference architecture for the gas turbine control system software product line is to provide standardised patterns, structure and framework for the application, enabling the hosting of components that contain variation. Our reference architecture is an evolution of the architectural concept used for the design of single- system solutions. The major changes were to address the shortfalls of this concept for the development of a product line; in particular the explicit support for variability. This was highlighted in an independent ATAM [117] assessment of the single-system architecture from the viewpoint of its suitability for use on a product line development [118]. In addition, we addressed lessons that emerged when adopting the architecture on a second system, primarily in the area of component interface identification and management. The reference architecture contains three main facets:
1. Architectural Framework
The Architectural Framework consists of a definition of a Platform (framework aspects that exist at runtime) and an Environment (design, verification and management processes and tools to support the use of the platform). The framework identifies the standard software structure to be employed, defined in terms of software abstraction layers and communication interfaces. In this way, it structures the software system to solve a particular class of problems – here this is defined as software for high-integrity, real-time control, protection and monitoring systems. This very abstract, high-level software system scope definition actually allows the software architect to start to construct an appropriate architecture framework early in the project development cycle.
87 Trusted Product Lines – PhD Thesis S G Hutchesson
The framework provides the following as standard:
Architectural Layers and Interfaces
Computational Model (incl. Data Typing)
Real Time Scheduling Support (including initialisation and modal support)
Data Transport Infrastructure for distribution
Monitoring for testing purposes
Utilities for commonality of implementation
2. Components & Component Rules
A Component provides a set of cohesive functional software and associated provided and required interfaces. Each component has a well-defined purpose but may contain variation points to enable system variability to deliver a product line instance. The reference architecture does not necessarily identify the specific components for a particular application; however, the rules and constraints that candidate components must respect are defined as part of the reference architecture.
3. Deployment
The Deployment view shows an instance of the framework deployed on a particular microprocessor, with an allocated, instantiated set of components and bound set of interfaces. The Reference Architecture necessarily describes the process by which deployment is achieved; however, specific deployments are required for each microprocessor within each product instance.
4.3.2 Architectural Constraints
To enable the reference architecture to be defined, a set of constraints must be identified against which the architecture concept can be judged (usually qualitatively). Without a set of (preferably ordered) constraints, it is difficult to make decisions and trade-offs.
4.3.2.1 Product Line Constraints
The following set of constraints on the reference architecture were identified to aid the definition and management of the product line.
1. All software product line variation points shall be visible, identifiable and traceable in the product line architectural model (within the framework or within a component) Rationale: The intent is to deliver a BAPO Level 4 architectural solution. This specifies that “…all products are developed based on the defined family architecture. In
particular, it specifies how and when to configure variants” [16]. The reference
architecture is the primary vehicle to describe allowable solution-space variation in the product line.
2. All variation points identified in the architecture shall be traceable to identified product line stakeholder needs or domain configuration options (e.g. engine and airframe configuration).
88 Trusted Product Lines – PhD Thesis S G Hutchesson
Rationale: There needs to be a rationale for every variation point in the software. Unnecessary variation should be eliminated. If architecture and component variation is purely identified by analysing variation in previous project instances, then there is the danger that needless variation may be introduced.
3. All variation point choices that configure a product line instance shall be visible and traceable in the deployment model for that product instance.
Rationale: There needs to be clarity in the choices made to configure a product instance – there needs to be an audit trail for each of the decisions made in selecting the specific product variants.
4.3.2.2 Architecture Design Constraints
A number of different software architectures may produce a solution that meets the functional requirements of a system; very few will meet both the functional requirements and the applicable technical and business constraints. The key, therefore, to a successful architecture and architecture-driven development process is a clear set of prioritised technical and business constraints.
These constraints can be modelled in the Artisan Studio UML tool using a “Constraints Diagram” as shown in Figure 40.
The blue curved-cornered rectangles describe constraint types, and the yellow rectangles describe instances of these types.
The diagram convention is that the constraints are shown in descending order of priority from left to right. The prioritisation of constraints enables the resolution of conflicting design approaches via trade-off analysis for example.
FIGURE 40PRIORITISED ARCHITECTURAL DESIGN CONSTRAINT DIAGRAM Safety Performance Maintainability Portability Testability Software DAL {DO-178B Level A} Independence {Independent Control and Protection}
Complexity {As simple as possible (and no simpler)}
Utilisation {CPU Utilisation <50% at EIS}
Response {All hard real time transactions met}
Lead Time {Minimise lead time of a modification}
Configurability {Efficiently accomodate data changes}
Effort {Minimise testing effort as a % of overall development cost} Platform Abstraction
{Facilitate migration to other hardware platforms} Design constraints in order of
importance Safety Performance Maintainability Portability Testability Software DAL {DO-178B Level A} Independence {Independent Control and Protection}
Complexity {As simple as possible (and no simpler)}
Utilisation {CPU Utilisation <50% at EIS}
Response {All hard real time transactions met}
Lead Time {Minimise lead time of a modification}
Configurability {Efficiently accomodate data changes}
Effort {Minimise testing effort as a % of overall development cost} Platform Abstraction
{Facilitate migration to other hardware platforms} Design constraints in order of
90 Trusted Product Lines – PhD Thesis S G Hutchesson
We describe the constraint set shown in Figure 40 in more detail below: 1. Safety
An overall constraint called “Safety” covers the requirements to demonstrate the software, when integrated within the target system, meets the integrity and availability targets required for safe operation in service:
a) Software shall be developed to the requirements of DO-178B/ED-12B Level A b) Control and Protection functions shall be independent
c) Software designs to be made as simple as possible (and no simpler) 2. Performance
The software is embedded within a real-time control system and has to meet hard real- time deadlines to comply fully with its operational requirements. The performance constraint also augments the real-time response requirements with resource utilisation targets:
a) Processor utilisation shall be < 50% at Entry Into Service (EIS) b) All hard real-time transactions are met
3. Maintainability
The business has on-going targets to reduce lead-time for developing control systems and respond to customer problems in a timely manner. In software terms, these become targets for modifiability and maintainability of the software once the original development is completed:
a) Minimise lead time for a modification b) Efficiently accommodate data changes
4. Portability
The business has on-going targets to reduce the cost of developing new control systems. The ability to port application software to other hardware platforms without incurring excessive redesign costs is important.
91 Trusted Product Lines – PhD Thesis S G Hutchesson
5. Testability
The testing cost of high-integrity software has been disproportionately high to date (~50% of development costs):
a) Minimise testing costs as a proportion of total development cost (Goal of 30% of total software costs)2