Real-time and Embedded Systems Forum
Berlin, Germany, 26th - 27th April 2001
Summary
The Real-time and Embedded Systems Forum met from Wednesday April 26th through to Thursday April 27th. The forum was divided into two sessions, the general open plenary session looking at current industry trends and the forum working group meetings. A joint meeting on quality of service for real-time systems was held as part of the Thursday session.
The general plenary session took the form of a set of invited speakers. The sessions ranged from presentations on embedded Linux, an update on POSIX real-time standardization, the distributed Real-time Specification for Java, and look at dependability in information infrastructures and a survey of the different approaches to real-time Linux. A recurrent theme was the tradeoff between time-to-market versus getting-it-right-first time, and selecting the right tool for the application.
The working group meeting for the forum included a joint session with Quality of Service Task Force, and a member's session in the afternoon, and a teleconference with the Security Interest group in the evening. A brief summary follows below, further details of these meetings are on the members only section of the website.
Working Group Session Summary
It was agreed to establish a joint working group on Quality of Service. An initial work item to be tackled is to to produce a canonical example or examples that will then be used to identify a set of requirements to achieve Quality of Service.
The paper produced by the profiles group on how to state conformance requirements and select profiles is progressing and we expect to complete next quarter. It was agreed to add information on the new profile 55 as an example of how to define an additional profile.
On item raised as a result of the plenary was the recognition of the potential duplication between the POSIX.13 profiles and the EL/IX specification (from Red Hat). It was agreed that further investigation is needed to identify the overlap, and that we should discuss with the parties whether there is a potential for cooperation and integration. This would avoid unnecessary duplication and confusion in the marketplace.
The Security Interest Group met via teleconference. It intends to output a call for information shortly. The current thinking is that they believes that there are only a few items specific to security for real-time and embedded systems, but that they would like to validate this assertion with a baseline to identify what is missing. It is recognized that this may need to be segmented by industry.
Looking forward the priorities for the forum are presently as follows:
The future meeting schedule for the forum is as follows:
Andrew welcomed the attendees to Berlin
In his introductory presentation he introduced the Real-time & Embedded Systems Forum and outlined the motivations for its creation. He proposed that the industry is entering a new era of so-called "post PC computing", and that smart devices (devices containing microprocessors yet not thought of as computers) were going to become pervasive. This is all resulting in increasing complexity and thus increased time-to-market.
This led to the formation of the forum, which is attempting to reduce the time-to-market, some members of the audience also noted that getting it right was also an important factor for this market, as the costs of bug fixing once embedded devices have been deployed is often prohibitive.
Andrew stressed that a key part of the forum's mission was the sharing of knowledge and integration of open initiatives. He then showed a list of current members, and having outlined the scope of the forum (very big) he said how important collaboration is - the forum aims to build on and cooperate with other standards activities.
He outlined the forum's activities to date and then went through the OS Test Tool Architecture. After touching on POSIX profiles he reviewed the security issues and challenges. He looked at QoS in particular.
He concluded by reviewing the challenges facing the RT and Open Systems community and felt that the goal was to bring all relevant parties together, together with some underpinning test and certification programs to produce useful standards for this marketplace.
Manfred started by running through what he was going to present. He posed the question "Embedded Linux, is it real?" and concluded that having seen several products and projects in the past the answer was yes but with reservations. With Internet connectivity driving Post-PC computing Linux would cover about 60% of requirements but the rest would still have to be found or developed.
He addressed 'square pegs in round holes' in that whilst the PC market has become almost completely standardised it is a very different story with embedded systems. There are advantages of the many-to-many aspects of open source software and he compared embedded to desktop. The various parameters of embedded Linux were looked at and the problem of fragmentation was highlighted; whilst configurabilty is not a magic wand it can solve some kinds of fragmentation.
He showed how standards come in many flavours and that good standards were really hard to find and then maintain. A discussion ensued ending with the observation that if one has too many standards then one might as well not have any!
ELIX (Embedded Linux) was presented and how it worked. He went through the 5 goals of ELIX reiterating that too many standards led to no standards.
Much work is going on within RT Linux and whilst the RTL market place may be limited, it is not small; Nokia has sold 200m devices in the last year. Memory management is needed in both software and hardware with each having its overheads and effects on RT.
Finally he put it all together with 5 examples which were Storage attached networks (SAN), Web Phones, SOHO Router, PDAs and Servers and concluded by quoting Michael Tiemann, CTO Red Hat.
"Linux has faced tremendous challenges on a variety of fronts. We knew that the greatest challenge facing Linux in the embedded market would be the threat of fragmentation. I am very pleased that ELC has facilitated the endorsement of single platform standard based on existing technologies, practices, and requirements important to the ELC membership. I am sure this will help Linux achieve the stature in the embedded market that it has achieved in other major segments, and Red Hat looks forward to making major contributions to ensure the success of this specification".
One mystery this talk did not solve was why the POSIX spelling of realtime does not include a hyphen ! This summary uses real-time with the hyphen.
Andrew started by addressing the scope of POSIX, outlining its purpose and also highlighting what it was not addressing -- it is a specification not an implementation. He reminded us that a standard API was not a piece of code but a piece of paper defining what code had to do, and that it formed a contract between the application programmer (who can code to that stable API) and the system implementor (who can provide the standard interface yet still be free to change and optimise the underlying implementation behind that interface).
There are many (most academic) definitions of real-time and its flavors -- Joe Gwinn's definitions for hard and soft real-time were presented based on many years in the trenches building large-scale embedded real-time systems. The key issue is the performance metric -- usually throughput for non-realtime systems, and latency for real-time systems. Platforms intended for traditional data-processing applications generally have operating systems optimized for maximum throughput at the expense of latency. Whereas systems intended for real-time applications will be optimized to have a low and predictable latency at the expense of throughput. Thus it is very important to measure the distribution of latencies under load so as to render the best comparison.
The presentation then looked at Embedded Real-time and noted
that the terms embedded and real-time although often
used as synonyms are in fact independent and a system can be either,
both or none.
A computer is considered embedded if it is a component of a larger
system whose primary purpose is not computation.
Some perspectives on operating systems , their sizes and maturity was then
presented. The point of this was to counter certain claims that desktop
operating systems can be used in embedded real-time aplications. The
assertion is that larger, younger or more complex an operating system
the less reliable it will be and that the tool should be fitted
to the task. If reliability matters then the smallest, simplest,
oldest operating system that does the job should be selected.
As an example of what can go wrong when the wrong tool is selected
for the job, The Yorktown Incident was presented. The
Yorktown is a smart ship, that was rendered helpless when the
software it was running crashed. This was an example of inappropriate
use of a desktop operating system for a mission-critical and
safety-critical role.
The final section of the talk looked at the revision for the base
POSIX 1003.1 standard, presenting the timeline and how this
revision is being developed. This revision
is being handled as a joint collaboration by the IEEE, The Open Group
and ISO, and the industry at large, in a joint group known as
the Austin Group. This commenced work in 1999 and will complete
the revision during 2001. It is free to participate in and
all information including drafts is available on the web
at http://www.opengroup.org/austin/.
The presentation discussed the initial goals for coherent control flow
across multiple nodes and enabling application-defined criteria for data
consistency and failure detection.
Douglas started by stating the raison d'etre of real- time computing
is predictability of collective thread timeliness and that timeliness
predictability must generally be traded off against other properties.
There have been many "real-time" languages and he compared their pros
and cons; none of which have become popular in the commercial world.
Ada95 has been the most successful
JSR-50 is the distributed RT specification for Java. Java has become
popular in the commercial world and he looked at the history of Java.
A distributed (DS) system has application entities that exhibit multi-node
behaviors and can be categorized in various ways for various purposes;
he showed some of these. He continued by saying that a DS usually has
one primary application programming model and that a RT DS has acceptable
timeliness of multi-node application behaviors. A multi-node behavior's
timeliness properties must be used coherently on all involved models and
multi-node application behavior timeliness properties must be propagated
among nodes.
RT distributed Java systems can use RMI to propagate timeliness properties
Douglas stated. He went on with there being many ways to use timeliness
properties for scheduling coherently on each model. JSR-50's initial
emphasis is on control flow programming models with control flow having
compelling advantages as a native model for distributed RT software.
He stated that timeliness in a distributed RT control flow programming
models is end-to-end with control method invocations (and returns) being
location independent and other code being not. He gave an example of
a notional anti-air warfare system; this was a 3-flow model.
He continued by discussing distributable threads in great detail and
wound up by concluding that real-time Java was highly likely to be the
first successful real-time programming language.
The functional provision for hard real-time processing has been reduced
to a minimum. Nonetheless extremely short response times can be achieved
which are comparable with response times resulting from, for example,
C-based implementation. The typical architecture of application systems
is also reflected insofar as hard real-time is usually only required
for a small part of the complete system.
Wolfgang presented a history of the J Consortium from June 1998 through
to now. He continued by introducing the half dozen or so working groups.
He talked about the motivations for a uniform data access visiting the
starting point, the overall scope, typical RT/non RT scenarios and RT
objectives. He said that permanent objects within RT extensions were
a must and went on to consider several more permanent objects with the
requirement of preemptible garbage collection (GC).
He looked in detail at the overall architecture needed in an I/O data
access API and took us through the overall partitioning of I/O Data
Access. He looked at I/O nodes, device description and name service
within the configuration part. He painted an interrupt handling scenario
and looked at it within overall partitioning.
He then explained a dynamic execution model with reference to I/O data
access and discussed priorities within RT extensions. He looked at
configuration of interrupt response time evaluation paying particular
attention to the SYSTEM_PRIORITY parameter.
He concluded by presenting a RTDA Architecture (Prototype) model with
reference to extensibility.
Marcelo shared JRC's mission saying that it was not so much one of
producing technology but more one of throwing light on potentially
relevant systems. He showed the various institutions within JRC and
talked about what their areas of work were.
The main stress was the citizen's concern followed by the public interest.
He presented JRC's involvement with cyberspace with particular emphasis
on the trust needed for final users. Their privacy was paramount.
He stated that JRC's role was not just about introducing technology
but one of changing our socio-economic behavior. Risks are being
introduced and so it is best to understand them before it is too late.
IT is everywhere and is also a Pandora's box.
He showed us a model of the effect on the eCitizen from technical,
policy and social context. He introduced the 5th Framework programme
again stressing trust and dependability. He stated that embedded systems
should play a primary role in the ubiquity of computing and looked at
some forms of embedded systems within eEurope.
He went on to strategic issues again stressing trust & reliability.
Dependability is about the system and trust considers the viewpoint of
the final user. He stayed with trust and dependability highlighting that
there is as yet no agreement on information infrastructure. There are new
issues, which are not like traditional ones; information is not the same
as it used to be. He then went on to compare trust and trustworthiness.
He went through the recent workshop and what its background was.
He examined trends and actual & potential bottlenecks and concluded that
the main issue was risk viz. information is an asset; assets have value
which are therefore potentially damageable.
He reiterated that there was no universally accepted definition for
information infrastructures and declared that there were now some 15
different definitions of threat; there used to be just one which was
pertinent to the defense field. What is valid today may not be valid
tomorrow.
He went through security and survivability with security of information
assets and security being the mission. He looked at dependable real
time embedded systems posing what was there to rely on and what was
there to protect.
He concluded by re-emphasis of trust and confidence is the message.
Linux already has some soft real-time capabilities, but these are often
not sufficient for applications in the areas of multimedia devices and
machine control systems. There are several methods to archive guaranteed
timings to fit the advanced needs. This talk discussed the different
flavours and showed which real-time Linux extension is the best one for
which application.
Bernhard introduced himself and outlined hi career to date. He posed the
question as to what real-time really meant. "The real-time capability
of a system can be determined by the damage that occurs depending
on the event response times." He felt that Real-time was a buzzword
nowadays and it might be more appropriate to use QoS and this means
"things running smoothly".
He showed a comparison chart of real-time v. server operating systems
and demonstrated why Linux is not hard RT, offering 4 reasons why not.
He continued by discussing several methods of improving the Linux RT
capability which included: Classical techniques Decreasing the "nice"
value L-threads, POSIX scheduling Kernel threads and interrupts Scheduler
extensions Linux resource kernel QoS with Linux RT Sub kernel extensions
RTL/RTAI
He then ran through a comparison of real-time methods and their effects.
He then stated that Linux was rather like the idle task of a RT operating
system. He presented the origins and philosophies of Real Time Linux
(RTL) showing that RTL was POSIX 1003.1b compliant. He looked at
RTL architecture as well as an overview. He explained several RTL
functions/System calls and gave RTL application examples including Machine
Control Systems, Hurricane Hunter/LIDAR, Data Acquisition/cardiograms
and signal generation for real-time servos. Bernhard moved on to RTL
extensions, ports and legal issues
A Real Time Application Interface (RTAI) similar to RTL based on a Real Time Hardware Abstraction Layer (RTHAL). He talked about RTAI origins and philosophy; RTAI is POSIX 1003.1b compliant by using an overlay module to the native API of RTAI. We looked at an RTAI overview as well as several system calls. He concluded with RTAI examples including adjusting mirrors, software driven radio transmitter.
The Distributed Real Time Specification for Java-- Douglas M. Wells, The Open Group
Real Time Data Access-- Wolfgang Hartman, Siemens AG
Interdependencies and vulnerabilities in information infrastructures: implications for embedded systems
Marcelo Masero, Scientific Officer, Joint Research Centre (JRC), The European Commission
An overview of Real Time Linux-- Bernhard Kuhn, Lineo