An object-oriented modelling technique for analysis and design of complex (real-time) systems

Communication Channels can be implemented with very diverse methods. Communication channel implementations may be selected based 1upon the type (continuous data or message driven) and use of the channel as present in the Processing Model: • Continuous data communication channels have no impHeit protocols. Their implementation ranges from analog two-wire connections to simple (three-state) data buses. • Channels which carry events can be implemented with very simple methods. A two-wire conneetion suffices for a single event, multiple events can be encoded to reduce the needed number of wires. • Point-to-point communication channels can be implemented as simple serial or parallel connections with handshake protocols. • Alulti-source and multi-destination channels can be implemented by standard computer buses or communication networks. These include arbitration and error recovery protocols. Direct communication between software modules is regarded an interface, which will bedescribed insection 5.7.1. 5.6.2 Software implementeel processing entities Software implementations of an Abstract Processing Entity consist out of two parts: 1) The hardware on which the soltwa.re must run. The choice for this hardware is based upon the processing, interface and data storage capabilities needed by the Abstract Processing Entity. The hardware may range from a processing core embedded in an ASIC, via single chip microcomputers to complete (board-level) computers. 2) The software itself. This should be a translation of the behaviour description of the Abstract Processing Entity into the machine 'language~ of the chosen processor. This translation may be done via intermediate 'high-level' languages. 106 An Object-Oriented Modellng Techniqne for Complex (Real-Time) Systems 5.6.3 Hardware implementeel processing entities Hardware implementation of an Abstract Processing Entity means tbat a (new) data processing architecture must be designed. This architecture is specifically tailored to the functions which must be performed. Examples of functions which can be implemented in highly specialised hardware are fast Fourier transforms, data compression and decompression, data encription and decription, image generation and communication channel switching. Designing new hardware should only be done when existing impiementations cannot be used. This only happens for extreme situations, like very high data processing speed or ultra low power requirements. 5.6.4 Mixed hardware/software implementations Mixed hardware/software impiementations are obtained when 'general purpose' programmabie elements are combined with specifically designed hardware: • An alrea:dy existing processor's instruction set is changed. This can be done to tailor this processor to the processing requirements. • New hardware is added to an existing processor. This hardware may perform specific processing or interface functions. • A new general purpose processor is designed. Although designed to implement a specific Abstract Processing Entity, this processor may be re-programmed for other purposes. 5. 7 Interface specifications Interfaces must be specified to define the interconnections which will be present in the final system. The different Abstract Processing Entities are implemented separateiy. The interface specifications must be very thorough to ensure tbat implemenred processing entities can communieare when they are interconnected in the final system. There are various types of interfaces which can be present in the final system. The next sections describe these types, where they are used and what is needed to specify them. 5: High-Level System Arcbited:ure Synthesis 107 5.7.1 Software-software interfaces Direct interfaces between software implemented entities can only occur when these software modules run within a single processor. The interface between application modules and an operating system is a very important software-software interface. The two major types of software-software interfaces are the following: • Shared variables. These are generally used for non-event driven communication (for instanee to distribute status information). Shared variables can be specified by giving their storage format, memory space and address. • Procedure and fûnction calls. These are used to indicate an event or transfer a request. Their specification includes the formats of variables given and returned and how these are transferred. The way to invoke the actual routine should also be specified (for instanee direct call, tablelook-up or software interrupt). 5. 7.2 Software-hardware interfaces Software-hardware interfaces are needed when software interacts with input/output hardware. The software initiates an interactions through input and output instructions. External devices initiate an interaction with software through interrupts. Interrupts and input/output instructions provide only a primitive means of communication with external devices. It is possible to raise the hardware-software interface level by using more complex processor hardware and instructions. A good example of an ad vaneed hardware-software interface is the T9000 'transputer' ([pou91]). This processor is capable of sending and receiving data packets with a single instruction. A built-in multitasking operating system runs other tasks while a task waits for the completion of such a transfer. 5.7.3 Hardware-hardware interfaces Interfaces between hardware elements occur in a multitude of places. Each time there is an Abstract Processing Entity to Abstract Communication Channel connection, a hardware interface must be defined and built. 108 An Object-Oriented Modelling Technique for Complex (Reai-Time) Systems Section 6.2.3 provides the primitives which can be used for hardware-hardware communication. These 'primitives' include registers, queues and multiport memories. A multitude of different communication forms and protocols can be built using these primitives. 5.7.4 Sensors, actuators and adaptors Systems are not built using direct digital interfaces only. Special interfaces must be applied whenever special voltage or current levels are needed or non-electrical communication forms are used. Three basic types of these 'special interfaces' can be found in a system: • Adaptors are used to convert the voltage and current levels used within the data processing equipment into other levels and vice verse. Examples of adaptors are power drivers, input proteetion networks, digital-to-analog and analog-to-digital converters. • Sensors are used whenever values or states must be input into a data processing system. These are often non-electrical in nature. A sensor generally includes an adaptor for conneetion to the digital processing hardware. • .Actuators are used whenever a data processing system must effect changes to it's environment. These changes are rriostly of non-electrical nature. Like sensors, actuators generally include an adaptor at the processor interface. Designing interfaces like these is a far from trivial and often specialised job. Their importance is visible in the problem statement when the external interfaces of the system are non-electrical. Problem Domain Entities must be introduced during highlevel system behaviour analysis to convert these interfaces into sarnething more manageable. These Problem Domain Entities remain visible in the architecture phase. Their basic function does not change at all and willlater be implemented in hardware. 5: High-Level System Architecture Synthesis 109 5.8 Design consistency issues All design consistency issues which were described insection 4.8 are valid during highlevel system architecture design. The methods used to check for inconsistencies remain operational because the same basic model is used. Making preliminary implementation choices introduces three consistency issues which are not inherent to the basic model as described in chapters 2 and 3: • The processing and data storage requirements of an Abstract Processing Entity should remain within the profile of an implementation choice made for this entity. • The communication performed on an Abstract Communication Channel should be allowed by the profile of an implementation choice made for this channel. • All Abstract Processing Entities attached to a channel should be able to interface with it. 5.9 Design for testability Design for testability is the foliow-on of these 'maintenance and testing' functions described in section 4.4.4. These functions monitor and maintain the operational characteristics of the system. Design for testability focuses upon the final architecture and it' s components. Two major goals must be met: • Testing the system components in isolation. This can be used prior to system integration to make sure that the individual components are operational. • Testing the system as a whole. This can be done following integration to check the communication channels and the component' s adherence to the specified protocols. To reach these goals, the set of existing test messages should be expanded with messages which concentrate upon the architecture components. The actual implementation of the handling of these messages remains to be done during implementation of the system modules. Standard design for testability measures like boundary scan (board level) and scan testing (device level) should be used whenever possible. These methods can be applied automatically by integrating them in the design tools (this will be described in section 6.5.4). 110 An Objed-Orieoted Modelling Techniqqe for Complex (Reaf.. Time) Systems Both boundary scan and scan testing allow 'structural' tests to be performed. They are capable of checking all elements of the system structure down to the logic gate level. Structural tests are preferred above 'lünctional' tests, which only test the basic functions of a system. A functional test may leave some system elements untested. Functional tests have an advantage over st