Recent Results of the ITRON Subproject

TRON Project Int'l Symposium '98

Recent Results of the ITRON Subproject
12th12th Mar.
Mar. 1998
1998

Hiroaki Takada

Kiichiro Tamaru

Toyohashi
Toyohashi Univ.
Univ. ofof Technology
Technology
hiro@ertl.ics.tut.ac.jp
hiro@ertl.ics.tut.ac.jp

TOSHIBATOSHIBA CorporationCorporation§ TRON is an abbreviation of “The Real-time Operating system Nucleus.”§ ITRON is an abbreviation of “Industrial TRON.”

Hiroaki Takada

Recent Results of the ITRON Subproject

ITRON Subproject in the 2nd Stage
1st stage: real-time kernel specification
2nd stage: related standards for embedded systems
software components (software IP)- satisfying the preconditions for promoting the development and circulation of software components- standard API for software components
development environments- interface between real-time kernel and development environmentseg) language binding, debugging support
application-specific standards- satisfying application-specific requirements
Hiroaki Takada

Recent Results of the ITRON Subproject

Standardization Activities
ITRON Hard Real-Time Support Study Group(Nov. 1996 – Mar. 1998)
Kernel Specification WG
Application Design Guidelines WG
Embedded TCP/IP Technical Committee(Apr. 1997 –)RTOS Automotive Application Technical Committee(Jun. 1997 – Mar. 1998)
Java Technology on ITRON-Specification OS
Technical Committee(Nov. 1997 –)Hiroaki Takada

Recent Results of the ITRON Subproject

Importance of Software Components
Embedded systems is growing larger and morecomplex.
eg) digital camera
automotive applications
Some hardware components can be implemented withsoftware.
eg) software modem
voice compression/decompression
JPEG, MPEG
Development from scratch becomes more and moredifficult.
Lack of expertise is a serious problem.
Hiroaki Takada

Recent Results of the ITRON Subproject

Standardization for Software Components(1) promoting the development, circulation,and use of software components(2) standard API for software components inspecific fields
Standard API for Software Components
Standardization should be done for each kind ofsoftware components.
eg) communication protocols (TCP/IP)
file system, MPEG
should be started from most important fields
TCP/IP protocol stack
Hiroaki Takada

Recent Results of the ITRON Subproject

Promoting the Use of Software Components! Loose standardization is an obstacle for theportability of software components.

The standardization level should be raised.
next generation µITRON kernel specification! Software components with hard real-time constraints
should be supported.

eg) software modem, MPEG

coexistence of software components with applications
while satisfying their real-time constraints
enabling use of multiple software components with
their own real-time needs
application design guidelines for R-T systems
Hiroaki Takada

Recent Results of the ITRON Subproject

Next Generation µITRON Kernel Spec.
µITRON4.0
motivations:improving software portability
incorporating new kernel functions- hard real-time supportissue:
improving software portability while keeping
the advantage of “loose standardization”
performance vs. software portability
approach:defining several profiles
profile = a standard set of kernel functions
for a specific range of applications
subsetting is still acceptable (for small systems)
Hiroaki Takada

Recent Results of the ITRON Subproject

Standard Profile
concept:
a set of kernel functions defined for raising
software portability- Software components should use only thefunctions included in the standard profile.
- Kernels should implement all functions
included in the standard profile.
system assumptions:
The whole software is linked to one module.
Kernel objects (task, semaphore, etc.) are
statically defined.

Hiroaki Takada

Recent Results of the ITRON Subproject

Standard Profile – Function Overview
still under discussions
including almost all level S functions of µITRON3.0
incorporating from level E:
fixed-sized memorypool
cyclic handler
detailed specification is revised
system calls with timeout
tslp_tsk, twai_sem, ....
strict standardization:
System calls invoked from interrupt handlers
should be iXXX_YYY.
Mailbox should be implemented with linked-list.
Hiroaki Takada

Recent Results of the ITRON Subprojectmodifications:
ient_int and isig_tim are added.
Some system calls are renamed.
pol_sem
preq_semSome terminologies are changed or clarified.
suspendsuspendedstatic API:
System calls for creating and deleting kernel
objects (task, semaphore, ...) are not included.
Kernel objects should be defined with static API.
cre_tsk(...) ...... system call (dynamic API) for
creating a task
CRE_TSK(...) ... kernel configuration description(static API) for creating a task
Hiroaki Takada

Recent Results of the ITRON Subproject

exception handlings:
Exception handling architecture is defined!
CPU exception handler- Exceptions are raised by the processor.
- Handlers are invoked immediately.
- Handlers are executed in non-task context.
task exception routine- Exceptions are raised with ras_tex system call.
- Handlers are executed in the task context.
- Handlers are invoked when the task isscheduled in the next time.
similar to UNIX signal handler, but much lighter(and simpler) mechanism
Hiroaki Takada

Recent Results of the ITRON Subproject

Extended Functions
Level E functions of µITRON3.0 which are notincluded in the standard profile are defined
as extended functions.
- system calls for creating, deleting, andreferring kernel objects- messagebuffer and rendezvous- variable-sized memorypool- alarm handler
etc.
Hard real-time support functions are incorporated.
- mutual exclusion with priority ceiling andpriority inheritance support- overrun detection
Hiroaki Takada

Recent Results of the ITRON Subproject

Vehicle Control Profile
A subset definition of µITRON
for vehicle control applications
has been proposed byautomotive engineerslevel Ea bit smaller subset thanlevel S of µITRON3.0
level Swithmodified mailbox functions+ stack sharing mechanism

standardvehicle
controllevel R
µITRON3.0

incorporated as another profile

Hiroaki Takada

minimumµITRON4.0

Recent Results of the ITRON Subproject

Minimum Profile without Wait States
Wait state is mandatody with the existingµITRON specifiations, and dormant state is optional.
should be exchanged!
Dormant state is useful for saving stack space.
All tasks can share one stack space if wait states
are unnecessary to be supported.
Many application systems do not require waitstate.
A profile without wait state should be defined as anintroductory specification.
Hiroaki Takada

Recent Results of the ITRON Subproject

Application Design Guidelines
for Real-Time Systems

two purposes:
guaranteeing real-time constraints of both
software components and application based onreal-time scheduling theories
RMA (rate monotonic analysis) is adopted.
providing novice system designers a good guidelines
to design real-time applications using a real-timekernelHow to divide a system into tasks?
How to assign priorities to tasks?

Hiroaki Takada

Recent Results of the ITRON Subproject

Framework of the Design Guidelines
application code fragments
grouping code fragments
into tasks/handlers

guidelines for the grouping
software components

extracting parametersof each task

standardized
parameters of tasks

assigning priorities
tuning process

failedschedulability analysis
succeededapplication software

Hiroaki Takada}based on RMA

Recent Results of the ITRON Subproject

ITRON TCP/IP API Specification
TCP/IP protocol stack is one of the mostimportant software components, today.
The socket interface is not suitable for (esp. smallscale) embedded systems.
necessity of dynamic memory management within
the protocol stackErrors occurred within the protocol stack
is not notified to the application.
difference between UNIX process model andITRON (RTOS) task model
status:in final discussion stage and will be published soon
Hiroaki Takada

Recent Results of the ITRON Subprojectapproach:based on the socket interface
The socket interface can be implemented
as a library on the proposed API.
difference from the socket interface:
TCP API and UDP API are separately defined.
“End point” abstraction is adopted instead of“socket” abstraction. TCP end point for waiting forconnection requests and TCP connection end point
are handled as different objects.
TCP APIs for reducing data copies are also defined.
Non-blocking calls and callbacks are supported.
The callback routine can be used for receiving UDP
packets.
etc.
Hiroaki Takada

Recent Results of the ITRON Subproject

Future PlanµITRON4.0 Real-Time Kernel Specification
planned to be published within 1998
Real-Time Kernel Debugging Interface
new standardization activity in 1998
- standard interface between ITRON-specification
kernel and debugging environments
Application Design Guidelines
Device Driver Design Guidelines
continued to be investigatedµITRON4.0 Specification Study Group
open study group for non-members
Hiroaki Takada

Recent Results of the ITRON Subproject

Summary
documents to be published in 1998
ITRON TCP/IP API Specification
JTRON ver.2 SpecificationµITRON4.0 Specification
Application Design Guidelines
standardization activities in 1998
µITRON4.0 Specification Study Group
Embedded TCP/IP Technical Committee
Java Technology on ITRON-Specification OS
Technical Committee
RTOS Automotive Application Study Group
Hiroaki Takada