Engineering the Development of Embedded Systems - Formal Methods and Hybrid Real-Time Systems - page 393

3 Abstractions and Reality

An idealized view of the development of a real-time program would consist of the
following steps:
1. Requirements engineering: formalization of the properties and operations of the
system in a domain specific language,
2. Transformation of the requirements definition into a program specification,
3. Refinement of the program specification into a program expressed in a real-time
programming language, and
4. Implementation and testing of the real-time program.

However, none of these steps can actually be carried out completely with rigour and
precision. Domain-specific languages and methods of reasoning are, at best, available
in very limited forms. There is no method by which a domain-specific requirements
definition can be transformed into a timed program specification, and no method to
convert the specification into a real-time program.
Semantic models for real-time programs (e.g. [Henzinger et al 1991]) are usually
constructed to simplify analysis and reasoning; they are chosen to be appropriate for
representing the problems to be solved and they provide an abstraction over the hard-
ware platform. There is no suggestion that the models are suitable for mapping directly
to the hardware: the logic for specifying and reasoning over real-time programs applies
over the abstract semantic model.
Real-time programming languages typically do not provide features for explicit tim-
ing or for controlling the allocation and release of physical resources. They provide a
level of 'platform independence' but this means that timing and resource control can
only be done at the level of the platform, perhaps by an operating system or real-time
executive. Finally, as Lee points out ([Lee 2005]), the execution time of an operation
of a program is often determined by the actual interleaving of executions of the pro-
gram processes as this will determine what information is in the cache memory (and
hence available for quick access) and what has to be retrieved from slower memories;
processor pipelining can further affect execution times. And the interleaving of process
executions may be controlled by their relative priorities, which may be fixed or variable.
Given the difficulty in computing such basic data as the execution times of a program
operation, it is surprising that so many real-time embedded systems work as well as
they do. A lot of this apparent reliability may be because (a) systems are designed
very conservatively and make minimal use of advanced processor features, (b) much
of the code for an embedded application is derived from existing code, and (c) there
is extensive testing, both before release and in the field: when millions of copies of a
system are in widespread use (e.g. as with mobile telephones), the chances of design
and coding errors being detected and eventually corrected are high, though at a price.

4 Requirements

There is increasing evidence that errors in defining requirements continue to be the
largest cause of software errors. [Marasco 2006] shows that while other causes of errors
are reducing, errors due to incorrect requirements remain steady at 50% of the total.