Real-time and Embedded Systems Forum
Austin, Texas, 18th - 19th July 2001
Summary
The Real-time and Embedded Systems Forum met from Wednesday July 18th through to Thursday July 19th and was well attended. The forum was divided into two sessions, the general open plenary session looking at current industry trends and the forum working group meetings.
Wednesday was an open plenary session with fifteen briefings. Sessions ranged from the Forum status update, updates from the Forum liaisons from OMG, SAE, UDI and NCITS , briefing sessions on Pervasive computing, Safety Critical software, and Real-time Security.
The current membership continues to grow, with five new members since the last meeting. Looking forward the planned deliverables for 2001/2002 are as follows.
The working group meetings for the forum on the thursday included a joint session with the Quality of Service Task Force, a parallel Security meeting, a session on Profiles and a discussion on Hard Requirements for Real-time Java®.
The Real-time Security working group have made progress with their charter and are putting plans together for a standard API set and accompanying certification program. The Profiling group addressed working with the Linux community on a profile for Real-time and Embedded Linux. New areas that the Forum is considering in developing workplans for include Safety Critical Software and Hard Requirements for Real-time Java.
The future meeting schedule for the forum is as follows:
Glen Logan, Forum Co-chair, Open Systems Joint Task Force
Glen welcomed the attendees to Austin.
Glen outlined the timetable for the day and the administrivia, and the proceeded. In his introductory presentation he introduced the Real-time & Embedded Systems Forum, outlined the motivations for its creation, listed the current members and the scope of the forum.
Dock introduced the briefing by reminding the group that OMG had been working together for five years, had passed 5 specs for CORBA and UML, there were multiple implementations available, and that RT technology transfers go on between RT CORBA and RT Java. She also stated the mission statement and scope of the mission.
She gave the following as to its positioning now:
She continued with an update on what is currently work-in-progress:
She then went through what was on the horizon: UML profiles for fault tolerance and QoS, Data distribution, Online replica updates, QoS for XML, Scan-like test interface, Temporal reasoning, RT security, Minimum / Embedded CORBA 2.5, Minimum services, RT Java / CORBA and reliable multicast. Se continued with the longer term initiatives: Additional protocols, Zero copy transport, UML hazard tool integration, RT transactions, RT fault tolerance, RT architecture models, Interoperable RT replicas, Additional scheduling disciplines and online updates efore finishing by summary.
Diane Schleicher
Diane gave a relatively short briefing which included:
Russ began with assumptions made concerning DoD RT requirements and continued with development assumptions for those RT requirements. He then outlined the history of NCITS and RT standards and went through an outline of RT requirements presented to SDOs. He explained the projects initially selected by NCITS R1 and the concept of "volunteership" when he ran through projects approved and underway. He stated that the R1.1 subgroup had been disbanded the previous day. He then looked at R1 and UDI along with the scope of RT in relationship to UDI.
He talked briefly about the following issue categories:
He finished with specifying that he and Bob Barnard were points of contact at www.ncits.org/tc_home/r1.htm
Kevin began by explaining what UDI is and continued with those within UDI going over the 4 main points in the "driver problem":
He then presented the UDI solution showing that it was the key to portability. He then went through the UDI technology demonstrating UDI as a technology enabler and presenting its innovative features.
He followed on with UDI functional areas and driver classifications. He showed two slides highlighting the path from application to UDI driver and and example of a driver hierarchy. He demonstrated channel communications and then explained metalanguages. He then presented a list of the available UDI documents, UDI's current status and its related activities. Before finishing with UDI contact information he called for participation.
R. Scott Lewis, IBM Software Group
Scott began by welcoming the members of the forum and immediately went on to defining what constituted a PVC device. He followed by considering common organization in the embedded and RT market addressing:
He then detailed the monolithic OS and microkernel OS after which he thoroughly addressed the RT Security policy..
He then ran through a PVC WESee (Websphere Everyplace Suite embedded edition) business model following with several implementation considerations such as IBM requirements for an embedded OS, concerns with eLinux implementations and marketed approaches to make Linux real-time. He continued it pervasive computing and WESee, WESee architecture, WESee Security and WESee Security service gateway.
Dave Emery, Mitre
Dave opened by defining safety-critical software as:
and described the characteristics of a safety program.
He then talked about software verification, "traditional" development and certification. He went through two key drivers for safety-critical software:
He moved onto a consideration of COTS and felt that the challenge was how to achieve cost savings via reuse of COTS, without compromising safety; at the same time he reminded us that safety was a property of systems, not software. He looked at what COTS developers could contribute and felt that the following 3 points defined "openness" for safety:
He finished by proposing that the Open Group look at how to facilitate the use of COTS in safety-critical systems. The first proposed action is to establish a common set of documentation and services provided by a COTS vendor to the system integrator/prime contractor. The intent of this is to facilitate the system integrator's certification process, while reducing costs for both the COTS vendor and the system integrator by pre-defining the work products that the COTS vendor will deliver. If this is successful, we can look at other issues such as establishing the list of safe programming practices/coding & testing requirements for COTS products designed for specific qualification levels.
Joseph Vlad, Wind River
Joseph broke his presentation into three areas:
Within the overview he talked about DO-178B software considerations in airborne systems and equipment certification circa 1992, DO-178B being a guidance document only and focussing on software processes and objectives to comply with these processes, the calling out in many certification requirements documents as the recommended method to obtain approval of airborne software and many other standards existing such as SEI-CMM, DEF STAN 00-55, ISO, DOD-2167 and IEC 61508. He also stated that DO-178B is not prescriptive and its objectives varied depending on how software failures can affect system safety. Here he compared the automatic landing software to the coffee maker in the aft galley software observing that these two types of software need not be developed with the same rigour and it was for this reason that DO-178B defines 5 software levels, A - F with failure in A being catastrophic tailing off to failure in F having no effect. He stressed that it was impossible to know 100% about software safety and that one simply ad to check, check, check and check again. He rounded off this part with a reflection on traceabilty.
Within the software verification section he talked about:
Within the VxWorks RTOS and DO-178B section he began by looking at the software components of a system and then described VxWorks along with RT kernel.
He finished off his presentation by going trough the following points associated with VxWorks Certification Strategy:
Robert Allen, Boeing Phantom Works
Robert opened by stating that security had been a showstopper for the use of COTS RTOS giving the following reasons for this:
concluding that with the exception of Raytheon and Green Hills that RTOS vendors did not think the return upon investment justified the required levels of investment.
He carried on by saying that for years "security" levels had been defined by the DoD's trusted computer system evaluation criteria Orange Book. However common criteria supersedes the Orange Book even though protection profiles exist tat were inherited from the Orange Book. He went on to talk about the levels of security within the Orange Book:
He then compared older type monolithic RTOSes to those of today looking at their modular scalabilty architecture and its threads, semaphores and interrupts etc.
He concluded by looking at what was needed:
Mike La Haye, OES Systems
Mike started off with a comparison of the various standards in use within industry and balanced the key metrics in the avionics industry against others. He explained where the time went in avionics projects and why they were so often over budget. He assessed future avionic trends both now and in the near future and explained what DO178B was along with its highlights. He completed the certification overview by penultimately defining the terms certified, certifiable and qualified; he then ran through specific certification challenges.
Mike then moved on to tool usage within the certification process beginning with those associated with components of a RT system. He addressed COTS and pondered on what certification was along with the issues and challenges of COTS software. He explained why the traceability triangle was the key embellishing it with a couple of thought-worthy quotes. He presented software tools, both avionic testing ones as well other types. Next the objectives and goals of the software verification process were highlighted followed by two areas within the requirements based testing environment viz. hardware / software integration and low level.
He followed this with an overview of software structural coverage explaining how to prove software structural coverage. He showed the purpose of notice N 8110.83 and gave its history, defining what a software development tool was and how the notice defined not only software development tools but also software verification tools. He completed this area by giving some examples of tool classifications, introducing tool qualification and the 3 questions to be answered to decide if tool qualification was needed.
He described section 6d and section 6e of tool operational requirements before completing with an elegant flow diagram summary to determine whether or not software qualified as a software development tool.
Edwin Lee, Raytheon
Edwin kicked off by stating the objective of his presentation was to stimulate discussions on the possible ways of implementing Information Security in Embedded, Real-time Systems effectively. He then presented the following abstract:
"This presentation discusses Security for Embedded RT Operating System
(RTOS) by considering a minimum set of Security Robustness in the
Operating System kernel (the CORE of the OS, not to be confused with
a special meaning of Kernel in the DII/COE paradigm) along with a set
of scalable, configurable security services. This Robustness should
give the OS an absolute last line of defense if all other protections
fail. It should also offer some minimum capability to support data
isolation, should it become a necessity. Beyond the OS Kernel and in
OS extensions, such as the network protocol stack and the board
interface module, Security APIs can be defined to support additional
security functionality, such as encryption/decryption, key management
support, and network security functions.
The set of APIs should
also be structured to be very efficient, tailorable and scalable,
giving the developers a free hand to implement what their
applications need without being overly cumbersome or rigid. If we can
do that, the "31 flavors" of Embedded RT systems developers
will benefit, and the users will benefit."
He stated that despite different applications every embedded system has an operating system that is usually "thin" and has minimal processing power and whilst a high performance embedded RTOS lacked protection and could be vulnerable so a secure embedded RTOS was burdensome consuming more resources. He went on to say that good security was a balance between acceptable risk and cost & performance. He then compared the scope of information security within the DoD and commercial environments. He gave examples of threats to an embedded RTS and then an example of a tailorable security architecture for an embedded RTOS.
He summarized with 5 points for kernel robustness:
and 7 points for security services extensions:
And he concluded that OS vendors should design in security and provide robustness and flexibility to developers; application developers should be security aware, ask for security capabilities from RTOS vendors and provide effective, easy-to-use security features to users who should also be security conscious.
Joe Weiss, EPRI
Joe started off by considering what considering what operational systems were and what they should be. He stated that RT systems unique attributes for safety should be:
He explained what he thought was vulnerable hardware along with vulnerable software and protocols. Other concerns he had were:
He then demonstrated SCADA vulnerability highlighting its message strings.
The points he included when recent assessments of the vulnerability of an electric company were:
and for a paper company were:
Sam Bowser, Aerospace Corp.
Sam defined his agenda as:
He gave the following extract as the purpose of the forum:
"Secure systems and real time, embedded systems are subject areas with many requirements, guidelines, and standards. Historically, real time systems designers have not included information security/assurance in their requirements. Our interest area is the intersection of real time and security. A growing number of systems exist today that have both real time (including embedded) and security considerations. The Real Time Security Forum expects the number of such systems to grow rapidly as we enter the information age of mobile, wireless connectivity. We recognize that different system domains have different security and real time requirements, so a single solution is not the answer. There is a need for an approach that system architects can use and apply within their own system domain, and yet maintain certain standard to allow portability among these different systems. There is also a need for tools the system software developer can use to address security issues for real time systems."For its scope:
"We seek practical solutions and tools that will allow the developer to apply security policy in a flexible cost effective manner. We seek technologies and practices that can enable a wide variety of system architects to make informed decisions. As with any architecture, this involves tradeoffs by the system architect. Areas of tradeoff include:For its background:
"Real Time (RT) system requirements are currently being found in systems ranging from manufacturing to state-of-the-art tactical systems. However, the inclusion of RT systems into these processes significantly alters the overall security environment. Information security/assurance usually has not been addressed as a design constraint. Addressing those security issues will present some serious challenges to overcome. The military for example places a tremendous reliance on global information transfer to all command and fighting elements of a war. Commercial enterprises have significant information security needs in the current global environment. Such reliance demands security of this information far beyond what is present today. Not only is detection of any intrusion on this global communication important but real time detection and immediate severing of the intrusion; and continued, unhindered, operation is a strong requirement. With Real Time required for Command and Control (C2), the security safeguard of RT systems becomes extremely critical. The impact of RT on C2 has security implications for the entire infrastructure in the US and globally for all countries. "For its problem statement:
"The problem focus is upon embedded systems since they present the most difficult application area. Many embedded RT processors control critical systems. The range of critical RT systems includes chemical processes, power plants and grids, traffic control, manufacturing production lines, avionics, missiles, strategic defense systems, etc. Human lives, regulatory compliance, mission success, and even national security often depend on these RT systems properly functioning as designed and with little margin for error. Because of the unique nature of the RT operating environment, the protection of embedded RT systems presents a unique challenge for the system designer.And finally for its possible solution:
"We propose as a possible solution the creation of a RT Security API. The RT/OS vendors would be asked to support a standard API so that developers could tailor the security environment to the requirements of the domains supported by the software under development. Guidelines would be developed to provide the basis for the API creation using the Open Group as the coordinating body.
He went on to say that the security policy concerns included data isolation, information flow and the ability to be extended to time isolation whilst the security policy enforcement mechanism requirements included non-by passable, always invokable, tamper proof and ability to evaluate. He continued by addressing security architecture, SCA security supplement and guards and monitors. Ten gave a software structure comparison and talked a little about middleware within security enforcement before looking at the benefits of separation within the kernel security arcitecture.
His conclusions were each layer enforces its own portion of the security, the application becomes a full partner in defining and enforcing application-specific, security policies and layered security enforcement simplifies security evaluations.
He wound up with some salutary precautions and felt that future developments would include: