Specification of Reactive Hardware/Software Systems - Electronic ...

5.6 Architecture and Implementation Decisions Statement 127
network topology;
fault tolerant architectures;
hardware/software partitioning;
analogue/digital hardware partitioning;
floor-planning;
board/back-plane partitioning;
hardware to ASIC partitioning;
co-operating processors and peripherals.
Our previous research describes various sorts of architectures for mixed hardware/software
systems more extensively, with various illustrations of structures
[vdP93a].
The above list of schemes contains elements that concern system, hardware, and software
structure. For example, software is often denoted as concentric layers or shells
around a hardware platform. Some of those layers may be purchased products, for
example a real-time operating system for an embedded processor. The rest of the system
must be really developed. The interfaces with such a layer must be determined
precisely. It is needlessly to model all details of internal behaviour of a purchased product.
Prescribed implementation, possibly based on purchased system modules, is found
often in industry. Use of experience with existing products and keeping stable relations
with industrial suppliers often play a role. Of course old solutions must be questioned.
However investments in development and production facilities are not thrown away
without good reasons. These aspects can lead to knowledge about implementations that
must play a role in the structuring of a model to prevent costly iterations.
5.6 Architecture and Implementation Decisions Statement
Although graphical notations are powerful communication tools they reveal only a part
of the essential information. The essence of architecture and implementations structure
design is taking design decisions. Such a decision may be the result of considering
a wide variety of alternatives. In general, design decisions are not well documented.
Alternative solutions and the properties that have been considered for making an ’optimal’
design decision should be documented. Bare observation of a structure diagram,
designed by someone, shows nothing about the decision process itself. It may be presumed
that the designer did his best to take as much aspects in account as possible, and
that the structure is well thought-out. However this is not always the industrial practice.
Time pressure often necessitates to take a quick decision, without studying of further
alternatives. We are not in the position to condemn this approach. However, when
design changes appear to be necessary, it is crucial to be able to know what has been
studied, and what not, and on what criteria. Therefore we integrate so-called Decisions