Recent Results the ITRON Subproject

Hiroaki Takada

Kiichiro Tamaru

Dept. of Information and Computer Sciences
Toyohashi Univ. of Technology
1{1 Hibarigaoka, Tempaku-cho
Toyohashi, Aichi 441{8580, Japan

System ULSI Engineering Lab.
TOSHIBA Corporation
580{1 Horikawa-cho, Saiwai-ku
Kawasaki, Kanagawa 210{8520, Japan

Abstract
The ITRON Subproject started several new standardization activities in 1996 and in 1997, with which thesecond stage of the subproject has been launched. In
this paper, we brie y survey these activities and reporttheir recent results. The most important result of themis the proposed speci cation of ITRON4.0, the next
generation ITRON real-time kernel speci cation. In
this paper, the overview of the proposed speci cation ispresented the future plan to complete the speci cation
is described.

1 Introduction
Since the beginning of the TRON Project in 1984, the
ITRON Subproject has published a series of ITRON
real-time kernel speci cations. The reason for putting
the emphasis on the kernel speci cations is that many
embedded systems (especially, small-scale ones) use
only kernel functions.
As embedded systems grow larger and more complex, however, the need has increased for standardization e orts that take into account software components, development tools, and other speci cations
related to embedded system software. Among them,
we have determined to put an emphasis on software component-related standardization at rst in the
ITRON Subproject, and started several standardization activities described below. With these activities,
the second stage of the ITRON Subproject has started.
The standardization activities we started in 1996
and 1997 are as follows.

ITRON Hard Real-Time Support Study GroupThe ITRON Hard Real-Time Support Study Groupwas started in November, 1996 to satisfy the preconditions for promoting the development and circulationof software components. Speci cally, the study groupis focused primarily on the following two themes.
The rst is to resolve the issue that porting of software components up to now has been dicult due tothe large di erence in speci cations among ITRONspeci cation kernel implementations. This requiresthat the level of standardization of the kernel speci cations be raised while retaining the bene ts of loose
standardization.
The second theme is to support software components with hard real-time characteristics. Many software components demand real-time response. Examples include software modem, voice compression/decompression, and MPEG encoding/decoding.
What is needed is a framework that allows coexistenceof those software components with applications whilesatisfying their real-time constraints, and enabling useof multiple software components each with their own
real-time needs.
In April, 1997, two working groups, the kernelspeci cation WG and the application design guideline
WG, were formed and have been working on these twothemes.

Embedded TCP/IP Technical Committee
In order to promote wide use of software components,
the application program interface (API) of software
components should be standardized. The ITRONTechnical Committee called the establishment of anactivity for standardizing the API of the TCP/IP protocol stack, which has taken increasing signi cancerecently. As the result of the call, the Embedded
TCP/IP Technical Committee was established andstarted in April, 1997.
Though the widely used API for the TCP/IP protocol stack today is the socket interface, some inadequacies of the interface for embedded systems have been
pointed out. The major goal of the technical commit-

tee is to design a new TCP/IP API which matches therequirements of embedded systems.

It may be changed until the ITRON4.0 speci cationis xed.

RTOS Automotive Application Technical Committee

2.1 Motivations

With current practice, real-time kernels are dicult toapply to vehicle control systems, mainly because vehicle control applications generally require very short
response with very limited hardware resources, andbecause the overhead of real-time kernels is not permissible. In the recently developed systems, however,the control systems grow larger and require more sophisticated run-time software.
The RTOS Automotive Application TechnicalCommittee was started in June, 1997 to bring together
the requirements on real-time kernels used in vehicle
control systems and to propose a real-time kernel speci cation suitable for them.

Java Technology on ITRON-speci cation OS
Technical Committee

The ITRON Technical Committee established theJava Technology on ITRON-speci cation OS Technical Committee in November, 1997 to de ne the interface speci cations between ITRON-speci cation realtime kernels and Java Application Environments forembedded systems.
Java technologies are becoming increasingly important in embedded systems arena. Although several
Java ports have already been created on ITRONspeci cation kernels, there is no standard reference.
The purpose of this committee is to standardize thecommunication interface between Java applications(or applets) and ITRON tasks, and the implementation approach of Java threads with ITRON tasks. If
some extensions to the ITRON speci cation are foundto be necessary, the result will be re ected to the next
version of the ITRON speci cation.
Refer to the separate paper for the current statesof this committee [1].
In this paper, we will describe the recent results ofthese activities.

2 Next Generation ITRON Kernel
Speci cation
The most important result of the recent activities
is the requirements on real-time kernels, which will
be incorporated to ITRON4.0, the next generation
ITRON real-time kernel speci cation.
Note that the speci cation described in the following sections is the current snapshot of the discussions.

The two major motivations for designing new realtime kernel speci cation are to raise the portability ofsoftware components (and application software) developed on the ITRON-speci cation kernels and toincorporate new kernel functionalities, including thefunctions supporting hard real-time systems.

2.2 Standard Pro leConcept

The standard pro le is a set of real-time kernel functions, de ned for raising the portability of software
components. The software components (or application
software) which are required to be portable among different ITRON kernels are recommended to use only
the functions included in the standard pro le, and thereal-time kernels to which the software components arerequested to be portable are recommended to implement all the functions included in the standard pro le.
Extensions and subsettings of the standard pro leare still permitted in order to retain the advantages ofthe loose standardization policy of the TRON project.

Function Overview

The standard pro le of the ITRON4.0 speci cation
includes almost all level S functions of the ITRON3.0
speci cation. It also includes some extended functions. Some important extended functions are described in the following sections. Below, we will describe some other major modi cations from the level S
of ITRON3.0.
At rst, xed-sized memorypool and cyclic handler functions, which are level E functions in the
ITRON3.0 speci cation, are incorporated to thestandard pro le. The detailed speci cation of thecyclic handlers is revised. The system calls with timeout (tslp tsk, twai sem, etc.), which are also level E
functions in ITRON3.0, are now included in the standard pro le.
The API related to interrupt handlers is clari ed.
At rst, the system calls started with \i" (for example, iwup tsk) must be used within interrupt handlers.
The newly added ient int should be invoked at the
beginning of each interrupt handler described in the
C language, and iret int (renamed from ret int)
should be invoked at its end. isig tim, which is toinform the kernel of time ticks, is also introduced.
Some system call names are modi ed for consistency. Speci cally, preq sem is renamed to pol sem.

snd msg and rcv msg are renamed to snd mbx andrcv mbx, respectively.

Each level X option will be determined to be or not
to be included in the standard pro le. For example,
the TA WMUL option of event ags, with which multiple
tasks can wait for an event ag, is not included in thestandard pro le. Other options are still under discussion, currently.

Static De nition of Kernel Objects
The system calls to create and delete kernel objects(cre tsk, cre sem, etc.), which are level E functionsin ITRON3.0, are not included in the standard pro leof ITRON4.0.
In most ITRON3.0 implementations without
those system calls, what kernel objects should be created is described in the kernel con guration le, instead. The syntax of the kernel con guration le is
not implementation-dependent and is not portable.
In the ITRON4.0 speci cation, in order to ease thesoftware porting, descriptions in kernel con guration
les are standardized. For example, the directive forcreating a task is CRE TSK (not that it is described incapital letters) and the parameters to it are basicallythe same with the cre tsk system call. With thisapproach, application programmers are requested to
study one API only.

Exception Handlings
Exception handling
functionsaretotally
implementation-dependent in the ITRON3.0 specication. In ITRON4.0, two functions for exception
handling, CPU exception handlers and task exception
routines, are de ned in the standard pro le.
The CPU exception handlers are to handle CPU
exceptions, such as zero-division or bus error. In thestandard pro le, though the API to de ne a CPU exception handler is de ned, how to write a CPU exception handler is not standardized. This is because theCPU exception mechanisms of processors have great
variety, and because it is dicult to standardize it withlow overhead. At least, a task exception routine must
be able to be invoked with a CPU exception handler.
The task exception routines are to handle exceptional events in task contexts. One task exception
routine can be de ned for each task. An exceptional
event are raised on a task with ras tex (or iras tex)system call. The kind of events is passed in a parameter to ras tex and is noti ed to the task exception
routine with its parameter.

Terminology
Some terminologies used in the speci cation arechanged or clari ed. For example, RUN state, WAIT
state, SUSPEND state, and WAIT-SUSPEND state
are renamed to RUNNING state, WAITING state,
SUSPENDED state, and WAITING-SUSPENDED
state, respectively. Another example is that \delayed
dispatching" will not be used in the ITRON4.0 specication. The same concept will be described that \theinterrupt handlers have higher priority than the task
dispatcher" instead.

2.3 Extended Functions for Hard RealTime Systems
Two functions will be introduced to ITRON4.0 as theextended functions for hard real-time support: mutual
exclusion mechanism with priority ceiling and priority
inheritance support and overrun detection mechanism.
The detailed speci cation of the functions is still underdiscussions.

2.4 Vehicle Control Pro le
One of the recommendations from the RTOS Automotive Technical Committee is (basically) a subset de nition of ITRON including only necessary functions
for many vehicle control applications. In addition, themailbox functions are modi ed to be convenient for
the applications. A mechanism to share a stack spacewith multiple tasks is also introduced.
Roughly speaking, the subset de nition is a bit
smaller than the level S functions of ITRON3.0, thus
is quite smaller than the standard pro le describedabove. The subset de nition will be incorporated tothe ITRON4.0 speci cation, as another pro le than
the standard pro le.

2.5 Real-Time Kernel without Wait StateThe other recommendation from the RTOS Automotive Technical Committee is a real-time kernel speci cation without wait state. In the previous versions of
the ITRON kernel speci cations, wait state is mandatory. It is thought to be the prerequisite for a real-timekernel.
In recent studies, however, many application systems, especially small-scale systems, do not necessarily require wait state. Without wait state, all the tasks
within a system can share one stack area, and thus
removing wait state is very e ective for decreasing
memory consumption and reducing task dispatchingoverhead. Though it is still questionable if a real-timekernel without wait state can be called as a \real-timekernel," it is useful to de ne such real-time kernel speci cation as a subset of ITRON an introductory speci cation.

3 Application Design Guidelines
3.1 Motivations
There are two motivations to de ne application design guidelines for real-time embedded systems. Oneof them is to provide a standard approach to design
an embedded system using a real-time kernel for embedded application designers. For example, how to
divide a system into tasks and how to assign priorities to them should be covered. We think that it
is impossible to cover all application elds of embedded systems with one set of guidelines, because of thegreat varieties of embedded systems. The set of design guidelines being de ned is an approach focusing
on real-time features of embedded systems.
Another motivation is to support software components with hard real-time characteristics. In order tomake software components with hard real-time characteristics coexist with applications while satisfying
their real-time constraints, both of the software components and the applications should be designed following a set of rules, or design guidelines.

3.2 Overview of the Guidelines
In order to guarantee the real-time constraints of application systems, the application design guidelines
adopt the rate monotonic analysis (RMA) [2] as thebasic scheduling theory. With the RMA theory, ahigher priority should be assigned to a task withshorter deadline (this policy is called deadline monotonic scheduling).
The guidelines are organized as follows. At rst,
the application system should be divided into processings which are basic computation units constituting
the system and which correspond roughly with functions in C language or subroutines in assembler. The
guidelines do not cover this step, but show how toconstruct processings into a task. To do that, parameters representing the real-time characteristics of theprocessing, including the deadline, the maximum execution time, the maximum execution frequency, andthe signi cance should be listed up.
Then, the processings having the same (or similar)
real-time constraints are built up into a task. The
priority of a task is assigned according to the deadline
monotonic scheduling policy. After those step, theschedulability of the system is checked using the RMA

theory. If the system is found to be unschedulable,some kind of tuning process should be applied.
When a sotfware component having real-time constraints is provided, the provided should present thereal-time characteristics of the component. The userof the component can check the schedulability of thesystem consisting of the software component and theirown application programs.

4 TCP API for Embedded Systems
4.1 Motivations
As described in Section 1, the socket interface is themost widely used API for TCP/IP protocol stacks.
The socket interface, however, has some problems
when it is applied to embedded systems. For example, a TCP/IP protocol stack supporting the socketinterface must depend on dynamic memory management facility. When memory space is running short,the protocol stack silently discards packets. This is
not suitable for many embedded systems.

4.2 Overview of the API
The TCP/IP API proposed by the Embedded
TCP/IP Technical Committee is the API for the TCP
protocol and the UDP protocol over IPv4 (version 4 of
the Internet Protocol). The other APIs necessary fora TCP/IP protocol stack product (for example, APIs
for managing the IP routing table and for managing
the ARP table) are out of the scope in the current
version.
Considering that many existing internet softwareare based on the socket inferface and that many software engineers are familiar with it, the proposed API
is based on the socket interface, and the problems inapplying the socket interface to embedded systems are
remedied. It is also possible to implement a library implementing the socket interface on top of the proposedAPI.
Some of the important di erences with the socketinterface are as follows.
 The API for TCP and that for UDP are sepa-

rately speci ed. In other words, the proposed
API is protocol-dependent, while the socket interface is protocol-independent. In addition, thecurrent version is focused on IPv4.
 In stead of adopting the socket abstraction, end
points for communications are directly handled.
Moreover, the end point to wait for TCP connection requests (which corresponds to a socket
on which listen is called) and the end point fora TCP connection are managed as di erent objects, while a socket is an abstraction of both objects. In the proposed speci cation, the former
one is named a TCP reception point (abbreviatedas \rep") and the latter one is named a TCP communication end point (abbreviated as \cep").
 A set of TCP APIs with which the number ofdata copy can be reduced is de ned in addition
to the usual read/write style APIs. Speci cally, tcp rcv buf returns the start address andthe length of the bu er in which the received
data is stored. After processing the data within
the bu er, the application program should calltcp rel buf to release the bu er space. The
APIs for sending data is de ned similarly.
 Non-blocking calls and callbacks are supported
for asynchronous handling of the protocols (thesocket interface of UNIX also supports them).
The infamous select call is not supported, because it can be emulated with the callbacks andthe event ag functions.
 When an UDP packet is received, the callback
function is called instead of storing the packet
within a bu er managed by the protocol stack.
Within the callback function, the appliation program should allocate a bu er space for the UDP
packet and copy the packet to the bu er using
udp rcv dat. Otherwise, the UDP packet is discarded. With this approach, the application canknow when memory space is running short.
The rst version of the TCP/IP API speci cationfor embedded systems will be nished very soon by theEmbedded TCP/IP Technical Committee. After that,
the ITRON Technical will approve the speci cation as
an ITRON standard after a review process.

5 Future Plan
In order to complete the ITRON4.0 speci cation, we
will start the activity of the ITRON4.0 Speci cation
Study Group in April, 1998. The study group is an
open activity, in that anyone can participate in the activity. According to the current plan, the speci cation
will be nished and published within a half year.
Another important activity we are planning to start
within 1998 is the interface standardization between
real-time kernels and debugging tools such as software
debuggers, in-circuit emulators (ICE), and logic analyzers. With a standard interface between them, making a debugging tool support ITRON-speci cation
kernels becomes easier and we can expect that more

software development tools will support ITRONspeci cation kernels.

6 SummaryIn this paper, we have described the recent results of
the ITRON Subproject. As the result of the activities
since 1996, several outcomes are to be obtained. The
resulting speci cations and the guidelines will be madeopen following the basic policy of the TRON Project.
The market environments surrouding the ITRON
Subproject are changing very rapidly. We will continue the e orts to catch up the the market requirements and to contribute for the advancement of embedded system technologies.

Acknowledgments
We would like to thank the members of the ITRONTechnical Committee and the members of the other
ITRON-related study groups and committees described in this paper for their support and e orts for
the ITRON Subproject.

References[1] Y. Nakamoto and H. Takada, \Integration of Java andITRON," in Proc. 14th TRON Project Int'l Symposium, Mar. 1998.
[2] M. H. Klein, T. Ralya, B. Pollak, R. Obenza, andM. G. Harbour, A Practitioner's Handbook for RealTime Analysis:

Guide to Rate Monotonic Analysis

for Real-Time Systems

1993.

. Kluwer Academic Publishers,

The ITRON Technical Committee provides regular information on the ITRON speci cations via the Internet,
including the latest English-language speci cations andthe ITRON Newsletter. The URL is \http://tron.um.utokyo.ac.jp/TRON/ITRON/".