CIAL FEAT RE SAFETY

it

The term ‘system architecture’ has many slightly different definitions and/or uses. A system architecture becomes essential when a number of subsystems are being integrated. Integration is not simply concerned with the communication between the subsystems but also any conflicting assumptions inherent in each subsystem. The Converge-SA methodology fits each definition of system architecture into one of four levels of abstraction. The resultant system architecture provides the basis for a family of working and workable systems.

he ability to integrate many and varied computer systems is proving to be very attractive for many applications. The result- ing systems, however, have the potential to be

extremely complex both to design and use, unless positive actions are taken to keep them under control. Many people, not aware of the pitfalls, believe that the development of a large system can be approached in the same way as for a small system, but with a bit more work. In practice a new type of problem often appears due to the increasing number of possible interactions between the various components and subsystems.

If this complexity is to be controlled, a comprehensible plan must be created early in the system development to guide all the subsequent activities. In fact as soon as a proposal is made to integrate two systems, an additional phase should be added to the development life cycle to consider the integration issues. The product of this phase is a system architecture to which all the integrated subsystems should adhere for them to be able to a- operate fully. A system architecture performs this task by providing a top-level coherent view of the assumptions being made, and a plan for their integration. This is in full accord with the demand that all safety-related systems should be simple, and that safety features should be incorporated, and made visible, from an early stage.

The Framework IV Telematics for Transport project Converge has produced a set of guidelines for the creation of system architectures for intelligent transport systems,l which can also be applied to other industry sectors, and this article describes the approach.

System architecture All systems have an architecture even though most

developers do not yet explicitly write it down. Thus, for example, when a decision is taken to use only two digits to indicate the year, this is equivalent to defining part of the architecture as ‘this program will only work with dates from a single century’.

The issue of architecture becomes of increasing importance when systems are created from the integration of two or more subsystems. The naYve approach states that systems integration is only about data communication. This, of course, ignores the other assumptions that each subsystem might need to make about the others, and that make up the complete system architecture.

All systems are designed to work in an environment (possibly more than one) and assumptions are made about that environment which are then built into the design. It is the top-level statements andor assumptions about a system which make up the architecture of that system, providing it with form and style as well as the more well known attributes of functionality, size, performance etc. The architecture provides the structure around which the system is developed. Once this structure has been defined, either implicitly or explicitly, it is usually very difficult and expensive to change it later. A knowledge of the system architecture is therefore vital.

Wovking and workable systems Once the existence of the system architecture is

recognised, it can be used for the benefit of the entire

COMPUTING & CONTROL ENGINEERING JOURNAL FEBRUARY 1998

TECHNOLOGIES FOR SOFTWARE SA system life cycle. The objective of a system architecture is to provide a stable basis for a working and workable system. The requirement that a system should be ‘working’ is obvious. A working system is not only one that has a set of fully functioning subsystems, but also one in which these subsystems co-operate fully to provide the full functionality required by the goals of the system. However, the need for a system also to be ‘workable’ is often overlooked in the rush to produce a system that can be seen to be doing something. A workable system is not only pleasant to use, but also easy to manage and maintain for its planned lifetime.

A system architecture therefore encompasses both the goal-oriented functions that provide the ‘working’ objective, and also the supporting functions that provide the ‘workable’ objective. There are likely to be a number of people for whom these objectives must be satisfied, and they are likely to be interested in different attributes.

For example, an intelligent road transport system intended to manage the traffic between two cities will have stakeholders that include: the motorway owner, the service providers, the road users, the police, and the maintenance contractors; and if the motorway crosses a national boundary then there is likely to be more than one of each of them. In addition there is a need to bring together a number of different engineering disciplines during the development and operation of the system, in particular traffic engineers, software engineers, civil engineers, and electrical and electronics engineers.

A system architecture must therefore provide flexi- bility so that solutions can be developed which satisfy the separate objectives of the various stakeholders in the environment chosen for the application. It must also lead to systems that are both manageable and maintainable throughout their lifetime.

System architecture issues During the creation of a system architecture there

are a number of issues that recur, and are associated particularly with the integration process. These include:

Command and control-all systems should have clear lines of command. Information interchange-it is essential to ensure that all the necessary inputs are available at the right place and at the right time, and that the outputs go to the right place at the right time. Collaborationeon occasions a number of organisa- tions agree to work together towards a common goal. Conflict resolution-when two or more subsystems are integrated there is always the possibility that some of the objectives of one subsystem may be in conflict with the objectives of another subsystem. A particular problem can arise when engineers from different disciplines are working on the same system, and they each have their own interpretation of what is wanted. Complexity management-failure to implement fully

functional systems can, in part, be traced to an inability to manage the actual, as opposed to the perceived, complexity. However, one must be aware of the danger of not making too many simplifications such that the solution becomes simplistic and hence unworkable? Verification and validation-at all stages in the creation of a system consideration must be given as to how it will be tested. The system architecture must also allow for the ready replacement of any subsystem or component that was found to be faulty. Emergent properties-an emergent property is one that comes into existence because of the way the parts of the system have been integrated; it cannot be allocated to a particular part, e.g. the property of ‘transport’ in a car cannot be allocated to any of the car’s components, just to the whole system.

Flexibility A system needs to be flexible to meet the varying

demands of the stakeholders, and to be able to respond to the stress of a changing system environment. However, underlying this desire for flexibility is also a desire that, once a function has been provided, the system will be stable and predictable in its configuration. Thus fixible systems must be built on stable architectures. An architecture provides a class of systems with a set of possible functions, although this set need not be fully defined; however, if a new function is required that lies outside this set, then it is the architecture itself which must be changed.

A system architecture therefore provides the means of achieving controlled flexibility, i.e. flexibility within a set of known constraints. In particular, there is usually a desire for an architecture to be independent of the technology used to implement it. This can be achieved by avoiding, wherever possible, all statements about a certain technology, or that imply a certain technology. Thus maximum flexibility of design should be achieved by minimising the assumptions specified in the system architecture.

Levels of architecture The popularity of the term system architecture is

causing confusion; in particular it has the effect of blurring the distinction between an architecture and a design, to the extent that many people do not even realise that there is a difference. When you visit two stately homes, each in the same architectural style, you do not expect them to be identical, as would be the case if they had the same design. An architecture is thus something at a higher level than a design, such that while it remains constant, many different designs can conform to it. Fig. 1 shows that we can identify three levels of architecture, with the system design at level 0 to emphasise that it is not really part of the system architecture at all.

We can envisage the process of creating each level

COMPUTING & CONTROL ENGINEERING JOURNAL FEBRUARY 1998

TECHNOLOGIES FOR SOFTWARE SAFETY

autonomous enterprises . level interoperability properties

1 single authority system properties level 2

overall system structure level 1 I

level 0 system design

Fig. 1 Levels of system architecture and design

of architecture as the identification of anything and everything which is needed to provide a stable basis for the working and workable system under consideration. Each level of architecture fixes those assumptions that need to be stable at that level for the environment(s) in which the system is to operate.

Command and control The level 3 and level 2 architectures contain the top-

level assumptions about the system, in particular the laws, rules, and command and control structures under which the system will operate. The primary functions and subfunctions are identified and organised in a working and workable manner such that these assumptions hold, any conflicts are resolved, and the desired emergent properties are recognisable. A level 3 architecture is necessary when the need for inter- operability between autonomous enterprises or authorities arises. While the nature of the level 3 architecture is similar to that at level 2, the issues to be considered at level 3 are likely to be different. The means of achieving consensus will also be different since the system architect will have to negotiate, rather than dictate, a solution.

Level 3 and level 2 architectures may be written as a

data flow

set of functions i L

set of functions

command flow

Fig. 2 Layered reference model

reference model and/or an enterprise model,3 the latter being particularly appropriate to describe the commercial and/or business relationships between the various enterprises or authorities within the system. If the system comes under a single authority then a level 2 architecture is probably the highest necessary.

Reference models Probably the easiest reference model to create and use

is the layered reference model shown in Fig. 2, which delineates the levels of jurisdiction within the system ar~hitecture.~ The functions needed by the system are grouped into layers such that:

each layer may take input data for transformation from lower layers or from the environment outside the system each layer may generate commands for itself or for lower layers output data may be sent to lower layers for display or transmission to the environment outside the system, but not for transformation.

This structure has a number of advantages, many of which are desirable in a safety-related system:

(i) One or more layers may be designated for safety functions only, and may be allocated to specialist staff for their development.

(ii) Since no layer needs the one above it in order to provide its basic functionality, the functions can be organised within the layers so that:

the system will degrade gracefully layer by layer after a (number of) failure(s) one or more layers can be disabled for main- tenance, while the lower layers still maintain a basic functionality.

For a large system it is usual to place in the higher layers those functions that are likely to be physically distant from the main activities, so that if the communications fail some basic functionality will continue. It is for this reason also that a safety-related system should have a basic safety layer, under local control, as low as possible in the reference model.

System structure The set of level 1 architectures defines the overall

structure of the system, and how the subsystems relate to each other. It will normally consist of at least four separate individual architectures, two of which are functional and two are physical, which should, as far as possible, be technology and/or manufacturer inde- pendent, though this is not always possible. They are non-deterministic meta-designs describing a class of solutions.s Any suitable method may be used to describe

6 COMPUTING & CONTROL ENGINEERING JOURNAL FEBRUARY 1998

TECHNOLOGIES FOR SOFTWARE SA

these architectures although, if they are to provide flexibility of design, they should not contain too much detail.

(i) Functional model Functional architecture-this describes the functions and subfunctions, the flow of data between them, and the main databases. Information architecturethis describes the data needed by the system and their interrelationships.

(ii) Physical model 0 Physical architectur+this describes the grouping of

the functions identified in the functional architecture into physical units, and the communication lines between them. The grouping can be very important for safety-related systems because it defines where, and hence under whose authority, the safety-related functions will lie.

0 Communication architectures-this describes the communication lines between the physical units both in terms of message sets, and the characteristics needed of the media. It is this architecture that will probably define the level of detail needed to be defined in the other level 1 architectures, especially for those system architectures that are intended to be open. This is because the systems derived from such an open system architecture are likely to need communication standards defined for use by all manufacturers; thus the architecture must contain sufficient detail for these standards to be defined.

The set of level 1 architectures must, of course, be consistent both within themselves and between them- selves!

System design Level 0 is not really an ‘architecture’ at all; engineers

have been quite happy to call this a detailed design for many years. It is a manifestation of the sets of level 1 architectures with each subsystem and component being fully described, and the technologies to be used, and all the necessary standards, having been chosen. A design is deterministic and describes, normally in detail, exactly how a particular model of the system will be created. There are no options remaining in a design?

Flexibility of design A level 2 architecture can lead to a family of level 1

architectures, and a set of level 1 architectures can lead to a family of level 0 designs. It therefore follows that, in order to have compatible instances at level 0, it is necessary to fix the architecture at level 1, and in order to have compatible instances at level 1 it is necessary to fix the architecture at level 2. Indeed it may also be true to say that in order to integrate successfully two systems at level N, they must have a common architecture at level

N+1. While this is a novel hypothesis it does go a long way towards explaining the current high failure rate of integrated systems.

Preliminary safety analysis Although, by definition, a system architecture is not a

design, nevertheless it is possible to perform certain safety analyses at this stage in the life cycle. The EU Framework 111 project Passport devised a methodology for preliminary safety analysis, which is entirely based on the top level desired functionality of the system.“ This methodology will identify the top level hazards of the system from which it may be possible to identify certain features which need to be added to the system architecture to mitigate their effects.

Conclusion A system architecture is therefore not a design, nor is it

a system, it is a description which forms the basis for a class of systems and hence for a set of designs. A system architecture describes all the attributes for a class of systems, and specifies those structures which are fixed, and those which may have multiple instances. For some systems it is the amalgamation of knowledge from diverse fields of expertise; indeed a system architect has to be a yack of all trades’ capable of covering all the parts (a holistic approach), and all the aspects (an ontological approach), for the entire life cycle? It should contain a description of both the functional properties and the behavioural properties. The functional properties form the basis of the ‘working’ objective, while the behavioural properties contribute to the ‘workable’ objective.

Acknowledgment The ideas contained within this article were prepared

under the Converge support action of the Telematics Application Programme, an RTD activity of the Euro- pean Community; they do not necessarily represent the view of the Commission.

References 1 JESTY, P. H. et al.: ‘System architecture guidelines’, Transport

Telematics Project Converge (TR 1101), 1997 2 NEUMAN, P. G.: ‘Computer related risks’ (Addison Wesley, 1995, ISBN

0 20155 805 X) 3 IS0 10746-1 (Draft): ‘Reference model of open distributed processing’,

1994 4 GIEZEN, J.: ‘System architecture: the development of the reference

model’, Proceedings of the 4th World Congress on Intelligent Transport Systems, Berlin, October 1997

5 CROW, M., BEEBY, R., and G A W C K , J.: ‘Constructing systems and information: a process view’ (McGraw Hill, 1996, ISBN 0 0777 062 0)

6 HOBLEY, K. M. et aL: ‘Framework for prospective system safety analysis4etailed safety analysis’, Drive I1 Project Passport (V2058), Deliverable No. 9, 1995

7 RECHTIN, E.: ‘Systems architecting: creating and building complex systems’ (Prentice Hall, 1991, ISBN 0 13880 345 5)

0 IEE 1998

The authors are with the Safety Critical Computing Group, School of Computer Studies, University of Leeds, Leeds LS2 9JT, UK.

COMPUTING & CONTROL ENGINEERING JOURNAL FEBRUARY 1998