2.3.2 (Message) Sequence Charts
2.8 Von-Neumann languages
The sequential execution of von-Neumann languages is their common char- acteristic. Also, such languages allow an almost unrestricted access to global variables. Model-based design using CFSMs and computational graphs is very appropriate for embedded system design. Nevertheless, the use of standard von-Neumann languages is still widespread. Therefore, we cannot ignore these languages.
However, the distinction between KPNs and properly restricted von-Neumann languages is blurring. For KPNs, we do also have sequential execution of the code for each of the nodes. We are still keeping the distinction between KPN and von-Neumann languages since for KPNs, the emphasis of modeling is on the communication and details of the execution within the nodes are irrelevant.
For the first two languages covered in this section, communication is built into the languages. For the remaining languages, focus is on the computations and communication can be replaced by selecting different libraries.
2.8.1 CSP
CSP (communicating sequential processes) [Hoare, 1985] is one of the first languages comprising mechanisms for interprocess communication. Commu- nication is based on channels.
Example:
process A process B
... ...
var a .. var b ...
a := 3; ...
c!a;--output to channel c c?b;--input from channel c
end; end;
Both processes will wait for the other process to arrive at the input or out- put statement. This is a case of rendez-vous-based, blocking or synchronous message passing.
CSP is determinate, since it relies on the commitment to wait for input from a particular channel, like in Kahn process networks.
CSP has laid the foundation for the OCCAM language that was proposed as a programming language of the transputer [Thi´ebaut, 1995]. The focus on communication channels has been picked up again in the design of the XS1 processor [XMOS Ltd., 2010].
2.8.2 ADA
During the 1980s, the Department of Defense (DoD) in the United States re- alized that the dependability and maintainability of the software in its military equipment could soon become a major source of problems, unless some strict policy was enforced. It was decided that all software should be written in the same real-time language. Requirements for such a language were formulated.
No existing language met the requirements and, consequently, the design of a new one was started. The language which was finally accepted was based on PASCAL. It was called ADA (after Ada Lovelace, who can be considered being the first (female) programmer). ADA’95 [Kempe, 1995], [Burns and Wellings, 2001] is an object-oriented extension of the original standard.
One of the interesting features of ADA is the ability to have nested declarations of processes (called tasks in ADA). Tasks are started whenever control passes into the scope in which they are declared.
The following is an example (according to Burns et al. [Burns and Wellings, 1990]):
procedure example1 is task a;
task b;
task body a is
--local declarations for a begin
--statements for a end a;
task body b is
--local declarations for b begin
--statements for b end b;
begin
--Tasks a and b will start before the 1st statement of example1 --statements for example1
end;
The communication concept of ADA is another key concept. It is based on the rendez-vous paradigm. Whenever two tasks want to exchange information, the task reaching the “meeting point” first has to wait until its partner has also reached a corresponding point of control. Syntactically, procedures are used for describing communication. Procedures which can be called from other tasks must be identified by the keywordentry.
Example [Burns and Wellings, 1990]:
task screen out is
entry call (val : character; x, y : integer);
end screen out;
Task screen out includes a procedure named call which can be called from other processes. Some other task can call this procedure by prefixing it with the name of the task:
screen out.call(’Z’,10,20);
The calling task has to wait until the called task has reached a point of control, at which it accepts calls from other tasks. This point of control is indicated by the keywordaccept:
task body screen out is ...
begin ...
accept call (val : character; x, y : integer) do ...
end call;
...
end screen out;
Obviously, taskscreen outmay be waiting for several calls at the same time.
The ADAselect-statement provides this capability.
Example:
task screen output is
entry call ch(val:character; x, y: integer);
entry call int(z, x, y: integer);
end screen out;
task body screen output is ...
select
accept call ch ... do...
end call ch;
or
accept call int ... do ..
end call int;
end select;
...
In this case, taskscreen outwill be waiting until either call chorcall intare called.
Due to the presence of theselect-statement, ADA is not determinate. ADA has been the preferred language for military equipment produced in the West- ern hemisphere for some time. Recently produced information about ADA is available from a web sites (see, for example [Kempe Software Capital Enter- prises (KSCE), 2010]).
2.8.3 Java
For Java, communication can be selected by choosing between different li- braries. Computation is strictly sequential.
Java was designed as a platform-independent language. It can be executed on any machine for which an interpreter of the internal byte-code represen- tation of Java-programs is available. This byte-code representation is a very compact representation, which requires less memory space than a standard bi- nary machine code representation. Obviously, this is a potential advantage in system-on-a-chip applications, where memory space is limited.
Also, Java was designed as a safe language. Many potentially dangerous fea- tures of C or C++ (like pointer arithmetic) are not available in Java. Hence, Java meets the safety requirements for specification languages for embedded systems. Java supports exception handling, simplifying recovery in case of run-time errors. There is no danger of memory leakages due to missing mem- ory deallocation, since Java provides automatic garbage collection. This fea- ture avoids potential problems in applications that must run for months or even years without ever being restarted. Java also meets the requirement to support concurrency since it includes threads (light-weight processes).
In addition, Java applications can be implemented quite fast, since Java sup- ports object orientation and since Java development systems come with pow- erful libraries.
However, standard Java is not really designed for real-time and embedded sys- tems. A number of characteristics which would make it a real-time and em- bedded programming language are missing:
The size of Java run-time libraries has to be added to the size of the ap- plication itself. These run-time libraries can be quite large. Consequently, only really large applications benefit from the compact representation of the application itself.
For many embedded applications, direct control over I/O devices is neces- sary (see page26). For safety reasons, no direct control over I/O devices is available in standard Java.
Automatic garbage collection requires some computing time. In standard Java, the instance in time at which automatic garbage collection is started cannot be predicted. Hence, the worst case execution time is very difficult to predict. Only extremely conservative estimates can be made.
Java does not specify the order in which threads are executed if several threads are ready to run. As a result, worst-case execution time estimates must be even more conservative.
Java programs are typically less efficient than C programs. Hence, Java is less recommended for resource constrained systems.
Proposals for solving the problems were made by Nilsen [Nilsen, 1998]. Pro- posals include hardware-supported garbage-collection, replacement of the run- time scheduler and tagging of some of the memory segments.
Currently (in 2010) relevant Java programming environments include the Java Enterprise Edition (J2EE), the Java Standard Edition (J2SE), the Java Micro Edition (J2ME), and CardJava [Sun, 2010]. CardJava is a stripped-down ver- sion of Java with emphasis on security for SmartCard applications. J2ME is the relevant Java environment for all other types of embedded systems.
Two library profiles have been defined for J2ME: CDC and CLDC. CLDC is used for mobile phones, using the so-called MIDP 1.0/2.0 as its standard for the application programming interface (API). CDC is used, for example, for TV sets and powerful mobile phones. Currently relevant sources for Java real-time programming include book by Wellings [Wellings, 2004], Dibble [Dibble, 2008] and Bruno [Bruno and Bollella, 2009] as well as web sites [Java Community Process, 2002] and [Anonymous, 2010b].
2.8.4 Pearl and Chill
Pearl [Deutsches Institut f¨ur Normung, 1997] was designed for industrial con- trol applications. It does include a large repertoire of language elements for controlling processes and referring to time. It requires an underlying real- time operating system. Pearl has been very popular in Europe and a large number of industrial control projects has been implemented in Pearl. Pearl supports semaphores which can be used to protect communication based on shared buffers.
Chill [Winkler, 2002] was designed for telephone exchange stations. It was standardized by the CCITT and used in telecommunication equipment. Chill is a kind of extended PASCAL.
2.8.5 Communication libraries
Standard von-Neumann languages do not come with built-in communication primitives. However, communication can be provided by libraries. There is a trend towards supporting communication within some local system as well as communication over longer distances. The use of internet protocols is becom- ing more popular. Libraries will be described in more detail in the section on system software (see page 195).