Architecture

Content and scope

An architecture is an abstraction of a concrete system representing:

In this chapter we shall describe:

Architecture models are important because:

Documentation

Together the application, the framework and the architecture complement each other to form a complete documentation.

Architecture reference model

In the system reference models we distinguish between abstract systems and concrete systems as illustrated in Figure 53.

Figure 53: Reference models for abstract and concrete system
Open figure

 

Concrete system

The architecture is a simplified model of the concrete system. Concrete systems are composed from real hardware and executable software that provide services to real users.

While abstract systems, described in application and framework models, are composed from abstract components, concrete systems are composed from physical components and software. It is the concrete system that really matters to the users, but it is the abstract systems that enable us to understand what it does and to ensure that its functionality has the desired quality.

As illustrated in Figure 53, concrete systems consist of:

For every new system development, the platform is an important design issue, as it determines important properties such as cost, reliability and flexibility. It also influences the way that applications and frameworks are implemented.

What is an architecture?

What

The architecture is an abstraction of the concrete system that emphasises high level hardware structure and software structure. It will not go into the implementation details but focus on the implementation principles and how functional and non-functional properties are satisfied. It will often be distributed and have additional support for internal communication, as illustrated in Figure 54.

Figure 54: Architecture reference model
Open figure

Objectives

By identifying key architectural elements, the reference model helps to structure architecture models and to guide their development. Although the model in Figure 54 is quite coarsely grained, it identifies elements that come from different domains where the driving forces behind change and evolution are quite different. Application evolution, for instance, may be due to new service requirements (market pull), while the reason for platform changes may be performance and price (technology push). Keeping such parts separate and as independent as possible, we believe, is a key to flexibility and profitability.

The architecture reference model contains the following main parts:

  1. Hardware. It contains the underlying structure of physical nodes and interconnections that may be classifies as:

    General platform hardware. This is hardware that is not application framework specific. It will typically consist of general purpose computers in a network.

    Application framework specific hardware. This is hardware needed for the particular application or infrastructure that the system implements. Here we find peripheral equipment, such as the panels in the AccessControl system, and other special purpose hardware.

  2. Support software, which contains such elements as:

    the operating system;

    middleware (e.g. CORBA) that supports distribution;

    support for application framework programming, for instance: user interface tools (GUI), database management tools (DBMS), language runtime support (for SDL);

    support for application framework input/output (I/O) (that is for interaction with hardware).

  3. Infrastructure software, which implements the necessary interface between the application and the support software.
  4. Application framework software. This is the software part of the framework implementation. It contains implementations of the:

    Framework application.

    Framework infrastructure.

In real-time systems a central software design issue is how to handle concurrency, timing and communication. To this end it is important that the architecture manages to model the organisation of concurrent software processes (also called tasks in some operating systems), how they communicate and how they are scheduled.

Other important issues are:

Generality

In the family area, architectures are supposed to be quite general and contain the variability needed in different system instances. As a minimum they must support the variability needed in applications.

It is generally a good idea to use the same basic principle we used to make frameworks from applications: to define a layered framework structure.

Applied to the hardware part, the architecture may be seen as a hardware framework made up by some (stable) general hardware and some (redefinable) application framework hardware.

In the software part, we find the basic operating system at the bottom, with the other parts as successive applications on top of that. We may organise this as several software frameworks on top of each other. Ideally the result is a high level software framework where all we need to do to generate a particular application is to supply the application specific code.

Differences between abstract and concrete system

A good designer must be well aware of the differences between the concrete and the abstract world. There are two main categories of such differences:

  1. Fundamental differences in the nature of components. Physical components are rather imperfect compared to the more ideal components of abstract systems. They develop errors over time, they are subject to noise, and they need time to perform their processing tasks.
  2. Accidental differences in the functioning of components. In both worlds there are concepts for concurrency, communication, sequential behaviour and data, but they are not necessarily the same.

Fundamental differences

The fundamental differences are related to: Processing time, Errors and noise, Physical distribution and Finite resources.

Processing time

An abstract system is not limited by processing resources. Consequently the balance between the traffic load offered to the system and its processing capacity need not be considered. One simply assumes that the system is fast enough to process the load it is offered.

The real world is vastly different on this point. Each signal transfer, and each transition of a process, will take some time and require some processing resources. Due to these differences, the focal point of implementation design is quite different from that of the functional specification. The challenge is to find implementations for the abstract (SDL) concepts that are sufficiently fast to meet the traffic load and response time requirements without destroying the validity of the abstract system models.

One major issue is to balance the processing capacity of the implementation against the offered traffic load.

In the AccessControl system, for instance, the average peak load is 600 validations a minute. This means that a central computer must process each validation in less than one tenth of a second. How much less will depend on the other tasks the computer has to do and the margin one wants against overloading the system.

A related issue is to balance the processing capacity against the requirements to response times. Again the abstract (SDL) system has no problems, but the implementation may be highly pressed to meet response time requirements. One must be able to perform time critical processing, e.g. fetching input samples, process the sampled information, and respond in a feedback loop, all within a maximum time frame. Such requirements may increase the demands on processing speed beyond the speed required to handle the traffic load.

The hardware software interfaces need special consideration. It is not unusual that the larger part of a computers capacity is spent doing input-output. Much can therefore be achieved by carefully designing the input-output interface.

A special class of time constraints originates from channels assuming time dependent synchronization. This means that the receiver has to be fast enough to catch all relevant signal information at the speed it is passed over the channel.

Since SDL descriptions clearly specify the external and internal interactions needed to perform given functions, they provide an excellent basis for estimating the processing capacity needed to meet load and timing requirements.

Errors and noise

Abstract systems may suffer from specification errors, but the abstract world does not suffer from physical errors. It is simply assumed that processes and channels always operate according to their specification. It is not assumed that processes will stop from time to time, or that channels will distort the content of signals. But in the real world such things happen. From time to time errors will manifest themselves as faults in the operation of channels and processes.

In addition to the logical errors introduced in the implementation, we will have to cope with physical errors. Hardware errors, physical damage, and noise are caused by physical phenomena entirely outside the realm of abstract systems.

The effect of errors and noise will often need to be handled explicitly in the abstract system models, however. One must consider what may happen, how it can be detected and how the damages may be limited. If one active object fails, for instance, how should the environment react? One must consider what an object should do if it never gets a response to a request, or if it gets an erroneous response. What should be the reaction to a channel going down? What if an object starts to produce crazy signals? What if a signal is sent to a non-existing receiver?

To some extent the answers depend on the physical distribution of abstract objects in the concrete system, and the physical distances that abstract channels must cover.

Physical distribution

Physically separate processes and channels may fail independently of each other. Channels covering long physical distances are subject to more noise and errors than channels implemented in software within one computer.

An SDL description does not tell anything about the physical distance covered by a channel. In reality, however, there may (or may not) be large physical distances. This means that transmission equipment and protocols are needed to implement the channel reliably. Thus physical distance may introduce new functions needed to support the implementation of channels.

In the AccessControl system we can expect AccessPoints to be distributed physically and to be far away from the central unit. Thus there will be a need for communication protocols on the channels between them.

A positive effect of physical separation is that errors are isolated. Errors in one unit need not affect the other units in the system, provided that erroneous information is not propagated into them. Thus, physical separation may improve the error handling. But there is no free lunch. Errors need to be detected and isolated to allow the operational parts to continue operation with the error present. Proper handling of this aspect can be quite complex, and will normally require additional functionality in the abstract models. This is one of the issues that we seek to isolate in the infrastructure.

Finite resources

All resources in a real system are finite. There may be a maximum number of processes the operating system can handle, or a maximum number of buffers for sending messages. The word length is restricted, and the memory space too. Even primitive data like integers are finite.

SDL, on the other hand, has an unbounded queue in the input port of each process, and allows infinite data to be specified. Hence the designer must find ways to implement potentially infinite SDL systems using finite resources. One way is to restrict the use of SDL such that all values are certain to be bounded. Another is to deal with resource limitations in the implementation, preferably in a manner transparent to the SDL level. In cases where transparency cannot be achieved, one must either accept deviation from the SDL semantics, or explicitly handle the limitations in the SDL system.

Accidental differences

The accidental differences has to do with: Concurrency, Communication, Synchronization and Data.

Concurrency

The model of concurrency used in SDL assumes that processes behave independently and asynchronously. There is no relative ordering of operations in different processes except the ordering implied by the sending and reception of signals.

This permits SDL processes to be implemented either truly in parallel on separate hardware units, or in quasi-parallel on shared hardware.

Physical objects in the real world behave truly in parallel. This means that operations within different objects proceed in parallel to each other at the speed of the performing hardware.

A "natural" implementation is therefore to map each SDL process to a separate physical object. This is not always cost-effective. An alternative approach is to implement many processes in software sharing the same computer hardware. The implications of this are twofold:

  1. The processes and channels will not operate truly in parallel, but in quasi-parallel, meaning that they will operate one at the time, according to some scheduling strategy.
  2. Additional support will be needed to perform scheduling and multiplexing on top of the sequential machine.

Normally, scheduling and multiplexing are handled by an operating system. The operating system can be seen as a layer that implements a quasi-parallel virtual machine on top of the physical machine.

Communication

Very basically there are two different classes of information one needs to communicate:

  1. sequences of symbols, or values, in a given order;
  2. symbols, or values, continuously for the time they are valid.

In the first case, the sequential ordering is important. In the second case, the sequence does not matter, only the current value at each instant in time.

The two communication forms are dual in the sense that one form may be used to implement the other. Consider the need to communicate a continuous value: the most direct implementation is to use a communication medium that will transmit the value continuously, such as a shared variable in software, or an electrical connection in hardware. But one may alternatively use a sequential medium, such as a message queue, to transmit a sequence of symbols representing the sequence of changes (events) in the continuous value. This will introduce overhead to reconstruct the continuous value.

Both forms may be used in abstract as well as in concrete systems, but it is not always the case that the same form is used. Therefore it may be necessary to make the necessary adaptations in the implementation.

Input from a keypad may serve as an example. The output signal from each button is basically a continuous "1" when pushed, and a continuous "0" when not pushed. But the system needs to know the sequence of key strokes, and not the instant values. Thus the value changes (events) need to be detected and converted to symbols representing complete key strokes. Event detection like this is often needed at the interfaces of a real-time system. It may either be performed in software or in hardware.

Visual signals on a display screen are another example. The user wants information presented as continuous values, and not as messages flickering across the screen. Hence the event oriented SDL signal has to be converted to a continuous value on the screen.

Channels crossing the hardware-software boundary need special attention. An atomic channel, represented by a line in SDL/GR, may turn out to be a mixture of physical lines, electronic equipment and software in the real system. The communication and synchronization primitives used in hardware will often differ from those used in software.

To sum up: we cannot expect to find SDL-type signals at all interfaces, and must therefore be prepared to adapt and convert. Conversion from one form to another will be necessary. This is often a time critical task needing careful optimization.

Synchronization

The act of aligning the operations of different concurrent processes in relation to each other is generally called synchronization. Synchronization is necessary not only to achieve correctness in communication, but also to control the access to shared resources in the physical system.

In SDL, synchronization is achieved by means of the signal queues of processes and channels.

Consider two SDL processes that communicate. The sending process may send a signal at any time because it will be buffered in the input port of the receiving process. The receiving process may then consume the signal at a later time.

This is a buffered communication scheme in which the sender may produce infinitely many signals without waiting for the receiver to consume them. It is often referred to as asynchronous communication.

Asynchronous communication may be contrasted with so-called synchronous communication, in which the sending operation and the consuming operation occur at the same time. In this case there is no buffer between the processes.

Synchronisation may be further classified into time dependent synchronization, in which the operations are not explicitly synchronized, and time independent synchronization, which depends on an explicit synchronization of operations (some kind of semaphore). In time dependent synchronisation the correctness of an interaction depends on the relative timing of operations. This is a frequent source of so-called hard real-time requirements. It is quite common in communication channels (e.g. Asynchronous Transfer Mode, ATM).

One will often find mechanisms that differ from the SDL mechanisms at the physical interfaces to the system. It is quite typical to find time dependent synchronization on physical channels. This implies that time critical event monitoring and event generation will be necessary.

A designer will be faced on one hand by the synchronization primitives available in the real system, and on the other hand by the synchronization implied by the SDL specification. Additional functionality will often be needed to glue the various forms together.

Data

SDL data is based on the notion of abstract data types where operations may be defined by means of axioms. An implementation will normally need concrete data types where the operations are defined operationally. Therefore, the designer may need to transform the abstract data types of SDL into more concrete data types suitable for implementation.

Architecture models

Objectives

Architecture models are intended to answer how a system is (going to be/has been) realised. Their focus is on the concrete system construction in terms of hardware and software components, and how it implements the abstract systems defined in the application framework. While the application framework has focus on functional properties and behaviour, the architecture has focus on non-functional properties and physical structures. The purposes of architecture models are:

The concrete system modelled by the architecture shall behave as defined in the framework and application models and satisfy the non-functional properties.

What

Architecture models describe the:

In the architecture object models, the hardware and software architectures will be defined to a level of detail from which implementation is well defined. They should be organised into a generic platform specific part and a framework specific part which is adaptable to different applications.

The architecture contains variability that needs to be bound in system instances. In fact, configuration of system instances may take place at the architecture level, if suitable tool support is available.

Figure 55: Architecture models
Open figure

 

In the architecture property models, the non-functional properties are expressed.

The architecture models are organised into a specification part, and a design part, as illustrated in Figure 55.

Qualities

The following qualities are sought:

Documentation

Together the application, the framework and the architecture complement each other to form a complete documentation. As long as the framework and the architecture is stable, only the application need to be supplied for each new system.

Note that the architecture serves as our (only) entry point to a complete description of a given concrete system. By following the relationships "upwards" to the framework we find models of the abstract functionality it provides, and by following the relations "down" towards the Implementation we find all the implementation detail.

Derivation of concrete systems

It is recommended to define a Method for framework code generation (automatic and manual), and a Method for system instantiation which define the procedures and tools for configuration and building of system instances. (The configuration and building of system instances shall be as easy as possible.)

Architecture model content

The architecture property models describe non-functional properties and the architecture object models describe hardware structure, software structure and relationships.

Architecture property models (non-functional properties)

Non-functional properties are more physical in nature than the functional properties. They express features of a concrete system that are not modelled by a corresponding abstract system, typically features related to performance, error handling, power consumption and physical construction. See Architecture non-functional properties for details.

Architecture object models

Object models should be layered according to the Architecture reference model, see Figure 54 and consist of Hardware models, Software models and Implementation relations.

Hardware models

Hardware models describe the hardware on a high level. Here we find a description of the overall hardware structure as well as the types of hardware components used to compose the structure. Hardware models shall identify at least all physical nodes needed to implement the abstract system. Whenever possible and practical one should make a hardware framework that separates between:

Software models

These are models of the software. Here we describe the overall structure in terms of processes, procedures and data as well as the component types used in the structure. Whenever possible and practical one should make software frameworks that separates between:

  1. Support software:

    the operating system;

    middleware (e.g. CORBA) that supports distribution;

    support for application framework programming, for instance: user interface tools (GUI), database management tools (DBMS) , language runtime support (for SDL);

    support for application framework input/output (I/O) (that is for interaction with hardware).

  2. Application framework software. It contains the application and the infrastructure (software) implementations, and may be classified as: automatic and hand written.
  3. Foreign code, code that is imported from other sources, legacy code, etc.

Software models will often be organised with one (framework) type model for each type of computer (address space).

Implementation relations

Implementation relations are used to describe which parts of the application frameworks that are implemented-by the various physical nodes and software nodes, and where detailed hardware descriptions and source code can be found.

Architecture model languages and notations

Object models will be used to express the hardware and the software models. In the old SISU methodology two special diagram types were used for this. As it seems, the forthcoming UML will contain notations intended for similar purposes. If they prove adequate, they will be adopted by TIMe.

For property models a combination of text, mathematics and figures will be used.

Architecture specification

Objectives

While the application specifications describe abstract system properties related to the system behaviour (functional properties) the architecture specification describe concrete system properties (non-functional properties) related to the physical construction. Application specifications serve several purposes:

  1. Before the architecture is designed it serves to specify required properties that the concrete system shall satisfy. Such requirements are sometimes called design constraints, because they constrain the possible design space.
  2. After the architecture has been designed, to document its provided properties in a way suitable for assessment, retrieval and (re)use.

What

Specifications apply to the physical architecture as a whole as well as to each type of component in it. Hardware components and software components are normally characterised by different properties. (Power consumption, for instance, is a hardware property, while code size is a software property.) As for other specifications, the main thing is to describe properties that are important for the external use of the system. Consequently the context model is most important, but internal aspects may also be relevant.

Architecture specification object model

Specification object models will not always be needed, and may be omitted when they follow from the non-functional requirements in an obvious way. However, object models are good at describing objects and relationships, and should be included whenever that kind of information is important.

  1. Hardware specification. This may possibly be split into a specification of the general hardware and specification of the application framework hardware:
  2. Context models that describe the physical structure of the environment:

    (distributed) hardware units;

    connections and interfaces in hardware.

  3. Content models that describe:

    (distributed) hardware units directly linked to the environment, and therefore visible by the environment;

    other hardware units that needs to be mentioned in the specification;

    connections and interfaces in hardware (note that the physical distribution of a system may be important, and the interfaces between these distributed units may be of interest).

  4. Software specifications; that may possibly be split into a layered structure according to the Architecture reference model.
  5. Context models that describe:

    software in the environment and external software interfaces.

  6. Content models that describe:

    software units directly linked to the environment, and therefore visible to the environment,

    other software units that need to be mentioned in the specification. This may typically be support software of various kinds and existing application software that shall be used.

    internal software interfaces if appropriate.

For hardware as well as software there may be general policies and engineering practices. These must be mentioned in the property models.

Note that variability is important. Try to express variability both in the number of components and in their types. One should for instance specify what range of platforms that shall be supported, and the maximum number of computers the system may contain.

Architecture non-functional properties

User and customer related properties are important for the user (or the customer/owner) while Company internal properties are more important for the company itself (see also Dimensions of the property concept):

Some properties applies generally to the architecture while other properties can be linked with specific parts of the object models.

User and customer related properties

These are:

  1. General properties.
  2. Properties related to the hardware context:
    • The physical environment:
      • temperature;
      • humidity;
      • vibration;
      • physical distribution and distances, etc.;
    • interfaces;
    • performance:
      • response times;
      • load capacity;
      • overload handling;
    • reliability and error handling;
    • security.
  3. Properties related to the hardware content:
    • use of platform hardware;
    • use of ready-made components, etc.
  4. Properties related to the software context:
    • software environment;
    • software interfaces.
  5. Properties related to the software content:
    • support software;
    • application framework software.

Company internal properties

These are such as:

Non-functional properties are expressed in a mixture of text, figures and mathematics. The precise form varies between different kinds of properties. Non-functional properties are to be associated with the object models.

Architecture design

Objectives

To describe the design parts of architecture models that:

What

Architecture design determines critical architectural issues such as physical distribution, communication schemes, support software and physical interfaces. Some of these may subsequently be reflected in the Framework model in order to describe the complete system behaviour.

The design will cover the overall structure as well as each type of component in it.

Architecture relationships

The external relationships are presented in Figure 56.

Figure 56: Architecture relationships
Open figure

 

Relationship architecture - framework

Nodes in the architecture will implement components of the framework. It is recommended that the framework structure is similar to the structure of the architecture so that there is a one-to-one correspondence between the two structures (at a suitable aggregation level).

Harmonising architecture - framework

Normally the framework is harmonised to reflect the architecture, while the architecture need not take the framework into account, see Relationships framework - architecture.

Relationships architecture - implementation

The architecture is an abstraction of the concrete system intended to give overview and promote understanding of its construction. It should cover all parts of the implementation so it can be trusted as a faithful representation of it. At the same time it should not go into details that are better described using hardware description languages and programming languages. Such detail shall be found in implementation descriptions that are referenced from the architecture.

Architecture models give added value to the low level implementation descriptions through overview and by providing a single entry point to the entire documentation.

Harmonising architecture - implementation

Architecture implementation

Harmonising architecture specification - design

When the architecture has been designed, the architecture specification shall be harmonised. It shall be correct with respect to the actually provided properties, and it shall cover every property of importance for external assessment and use. Properties not needed for that purpose should be removed even if they were included in the initial specification.

Architecture specification

Summary of static architecture rules

The architecture models serve several purposes, see Architecture models, and should be structured to fulfil as many of those as possible. In addition the Architecture reference model should be used to make a layered structure that facilitates evolution.

Documentation

Hardware models

Software models

Software framework

Developing architecture

What

This activity develops implementation Architecture models which consists of object- and property models organised as an Architecture specification and an Designing architecture.

It also develops a Method for framework code generation, and a Method for system instantiation, see Figure 57.

Figure 57: Developing Architecture
Open figure

 

Inputs

The main sources of input information are:

Outputs

Architecture development results in an implementation architecture that will behave as defined in the Application models and satisfy the non-functional properties. It will also define a method for (automatic) generation of application implementation code and for configuration and building of system instances.

Who to involve

Concrete system design involves specialists in electronics, mechanics and software design. Such specialists tend to have a limited ability to perform high level system design. As this is very important in architectural design, an interdisciplinary team is required unless people with sufficiently broad system design experience are available. The team should not be biased towards a particular technology, but be able to perform tradeoffs wherever the solution is open. Such openness in design solutions is often essential in order to achieve innovation.

Users are normally not much concerned about architecture. But for the customer and the manufacturer it matters quite a deal. Not the least because it determines lifetime cost, the ability to evolve and the ability to interoperate with other systems.

Architectural designers need to work closely with production people, and specialists in software, electronics and mechanics.

When to do it

This activity is only performed when the implementation mapping is undefined or needs to be changed. This occurs during the initial development of a system family and during maintenance, when changes in the Platform are needed e.g. because of changes in the support software.

In an initial development, architecture design will come before framework/infrastructure design. During normal application evolution, the generic architecture will stay the same, and system evolution can take place mainly at the application level.

What to do

Making architectures

The following strategy may be used when making the first architecture model for a new system family:

Evolving architectures

The following strategy may be used when evolving an architecture:

Specifying architectures

Inputs

Inputs to this activity are the same as for Developing architecture models as a whole, see Figure 57. There are two main sources of inputs: the market (represented by users and other domain stake holders) and the company itself (represented by product owners, production departments and service responsibles). Technology (that is what technology and solutions are feasible today) may be considered a third source.

Making architecture specifications

The initial architecture specification is normally made at an early stage before there are any application designs or frameworks. It shall express the initial requirements on the concrete system.

A possible approach is the following:

Architecture specification approach

  1. Consult the market and write down the general non-functional properties that it requires, see User and customer related properties.
  2. Consult the various company departments and write down the company internal requirements, see Company internal properties.
  3. Make the hardware specification object model.
  4. Make the software specification object model.
  5. Specify the non-functional properties that shall apply to each object and interface in the object models.

Evolving architecture specifications

The reason for evolving an architecture specification is that some properties are to be added or changed.

  1. Specify the new or changed properties.
  2. Analyse its impact on the architecture design and the specification object model.
  3. (If the impact is acceptable then) make the changes to the specification object model.

Designing architecture

Making architecture design

The main inputs are: (1) the Application models (in SDL or UML) and (2) the Architecture specification. When the architecture is made for the first time, there is normally not any framework.

The following step-wise procedure takes both hardware and software into account:

Evolving architecture design

This activity makes an incremental evolution of the architecture so that it satisfies a new specification increment. It involves the same basic activities as making architectures for the first time, only that the existing architecture is taken into account. At this stage of development an application framework may exist.

Trade-off between hardware and software

Guidelines:

Physical distribution

Mean peak load

Real time response

Reliability

Hardware design

The task here is to define the overall (architectural) hardware design. It is based on the division into hardware and software where the main hardware units were identified.

A possible strategy:

  1. Describe the overall structure of general hardware, i.e. computers, networks.
  2. Describe the application framework specific hardware.
  3. Describe the physical interconnections between the hardware units.
  4. Describe the signal synchronisation schemes and protocols to be used on the physical interconnections, to the extent they are not already covered in the specification.

Some guide-lines:

Physical distribution

Hardware similarity

Software design

See Software design for further details.

Implementation relations

Guidelines:

Implementation mappings

Software design

Guidelines:

Implementation mapping

I/O software

Software communication

Support software

External signal priority

Give time-critical external events priority over internal processing.

Internal processing priority

Give the processing of internal signals priority over the processing of external signals

Load control

When overload occurs, give priority to service requests already in progress and delay fresh requests.

Free-pools

Limit the size (the number of free buffers) of free-pools where it helps to control the internal load in a system, in particular at the input side.

Use a separate message buffer free-pool for each consumer of message buffers.

Generality

Optimisation