Distributed Real-Time Computing for Microcontrollers - the OSA+ Approach U. Brinkschulte, A. Bechina, F. Picioroaga, E. Schneider IPR, Institute for Process Control, Engler-Bunte-Ring 8 University of Karlsruhe Germany email:
[email protected]
Abstract New applications introducing restrictions in power consumption, heat, costs and available space lead to small microcontrollers becoming more and more important in distributed real-time systems. Traditional real-time middleware architectures don’t fit very well for these small devices. The paper presents an ongoing approach of constructing middleware for small devices by adapting the microkernel concept known from operating systems to middleware. This middleware called OSA+ is service oriented and consists of a small core, basic-, extension-, and user-services. The core provides only a restricted functionality, while the basic and extension services adapt and scale the system according to the application environment. A first (quick and non-optimal) prototype implementation offers a core size of about 60 kBytes and an average size of about 10 kBytes for a basic service. We consider this as a basis for further optimizations leading to yet smaller sizes.
1. Introduction Distributed real-time systems are state of the art. Real-time middleware helps to simplify the development, operation and maintenance of such systems. New applications introduce restrictions in power consumption, heat, costs or available space thus leading to very small microcontrollers becoming more and more important in the field of distributed real-time computing. Traditional middleware architectures are not very suited to support such small devices. This paper presents the OSA+1 approach. Based on microkernel concepts, a 1
OSA+ : Open System Architecture – Platform for Universal Services
new middleware dedicated to small low power devices is introduced. The work described here is ongoing. Section 2 gives a general overview of the OSA+ concepts and architectures. Section 3 deals with the real-time issues and section 4 gives an application case and first results. Finally, section 5 concludes this paper.
2. An Approach Using a Scalable Microkernel Real-Time Middleware OSA+ is a scalable middleware for real-time systems. It facilitates the development of distributed real-time applications in a heterogeneous environment. In contrast to object oriented middleware architectures like CORBA [1], DCOM [2] or RMI [3] and message based architectures like JMS [4], OSA+ is a service based architecture. Services communicate by exchanging jobs. A job consists of an order and a corresponding result. The order tells what and when to do this (release times, deadlines, priorities). The result is returned after the job has finished execution. This is more than pure message exchange (like in JMS), because the execution of the services is scheduled according to the priorities or deadlines of the jobs. A more detailed description of the job scheduling can be found in section 3. Because OSA+ is dedicated to small systems, a simple interface is necessary. Figure 1 shows the service interaction based on only six functions: two functions to send and execute an order or to return a result (SendOrder, ReturnResult), two blocking functions for synchronous reception of an order or a result (AwaitOrder, AwaitResult) and two non-blocking functions for asynchronous reception (ExistOrder, ExistResult). These functions form a simple, but flexible interface, which can be used directly or be a foundation to build object oriented interfaces, if necessary.
Send Order
Await Result
Exists Result
Microcontroller/ -processor 1
Await Order
Exists Order
Return Result
sizes, see section 3.2. First results on memory sizes of the core and the basic services are given in section 4. Additionally to the basic services and user application services, extension services can be written to add new functionality to the platform, e.g. error logging or job encryption.
Microcontroller/ -processor n
Figure 1: service oriented architecture Another aspect, where OSA+ contrasts to current standard middleware architectures is its microkernel approach. Full size middleware like e.g. CORBA is not very suited to small embedded systems, because it needs a considerable amount of memory and computing power. This is the reason why a stripped down CORBA version (Embedded CORBA) has been defined. Our approach is the other way round. Instead of stripping down an existing full size middleware, we define a new architecture consisting of small building blocks. We want to examine, if this approach scales better to very small systems than the ‘stripping-it-down’ approach. To realize this, we have adapted the concept of microkernels well known from operating systems to middleware. Figure 2 shows the overall structure. The core of the OSA+ platform offers only a basic functionality, which is registering of local services and local job exchange. This shall keep the core small. Furthermore, no parts depending on the environment (operating system, communication system, ...) are contained. Because the core is able to register and interact with local services, exactly these services can be used to adapt to the environment and to extend the functionality. We have defined a set of basic services for that purpose: the process service adapts to the operating system and is responsible for service scheduling. The memory service adapts as well to the operating system and is responsible for dynamic memory allocation. The event service deals with real-time events and time-related job delivery. The communication service adapts to the underlying communication system and is responsible for remote job delivery. The address resolution service deals with finding remote services. There are no differences between a basic service and a user service. The core platform treats them in the same way. This keeps the core small and simple. It allows to scale and adapt the middleware in an easy way. On very small systems, the core can operate standalone with a restricted functionality. As necessary, basic services can be added. Furthermore, it is possible to provide a basic service in different qualities and resulting memory
OSA+ Core (Microkernel)
Adaptation to the environment
Functional extensions
Figure 2: OSA+ microkernel architecture
3. Real-time Issues 3.1 Core Issues Since the core is kept on a simple, environment independent level and does not deal with issues like e.g. thread scheduling (this is the task of the process service), the core real-time issues are simple: • The core functions are divided into two groups: initialization functions (e.g. plug in a service) and operational functions (e.g. SendOrder). The initialization functions preallocate all necessary resources (e.g. memory) for the operational functions. So while the execution time of initialization functions may be unpredictable, the operational functions are completely static and offer a constant and bound time behavior. • The job queues maintained by the job delivery component of the core are prioritized. This means, high priority jobs will overtake low priority jobs in these queues. To maintain the priority of a job on all its way through the system, this priority is as well delivered to the process service (service scheduling) and the communication service (remote delivery).
3.2 Quality Assessment
of
Service
Control
and
The overall real-time behavior of a middleware depends on the underlying components like e.g. the operating or the communication system. This means, the core real-time issues described in the
3.3 Real-time memory service The OSA+ memory service is a good example for the use of the QoS report function. This service can report two important properties: • memory locking • real-time memory allocation If both are not present, no real-time operation can be performed at all because even so all needed memory is preallocated by the core initialization functions, it may be swapped out during operation by the OS. Fortunately, at least memory locking is offered by most OS or swapping is not implemented at all for microcontroller OS. If real-time memory allocation (this means the allocation time for a piece of memory is predictable) is available, the core can introduce more dynamics. Memory must not be preallocated by the initialization functions, but can be dynamically allocated by the operational functions. To make an example, if no real-time memory allocation is present the maximum job size and number of simultaneous jobs for a service has to be defined statically at initialization time. With realtime memory allocation this can be handled at runtime.
destination platform
/j ob res ult rec eiv lat ed es te nd of cy cle
job
source platform
cr e at l i v ed er i ng ea or rli de es r ts lat t es art o te nd f de or liv de of er rd de liv y ea eliv er e rli y es red t lat es s tar t te nd o f e de of xec liv e u er ing xec u tion ea tio res rli n ul es t sta t la rt tes of te de nd liv of er de y liv er y res ul tr lat ecei ve es te d nd of cy cle /j ob
by offering real-time features (like RT scheduling policies, prioritized communication, etc.), the event service plays an active role. This service is responsible for initiating all time triggered actions. Figure 3 shows the possible states and times of a job during job scheduling.
de
previous section are only one facet. The real-time properties of the underlying components are introduced to the core by the basic services (e.g. OS scheduling policies are introduced by the process service). Different configuration are possible: for example, with a real-time OS (→process service) but a non real-time communication system (→communication service), local jobs but not remote jobs can be handled in real-time. To deal with such different configurations, OSA+ prescribes that every service must provide quality of service (QoS) information for the platform and all other services, which want to use it. This is done by a special QoS report function every service must be able to execute. For example, the process service has to report the available scheduling policies (nonrealtime, FPP, EDF, etc.) by this function. Using the QoS report functions the core and the user services can evaluate the overall real-time properties. The QoS report function can be used as well to provide different qualities and resulting memory sizes for the same basic service. While e.g. a simple and small version of the process service offers and reports only one simple scheduling policy (may be FPP), a more complex version can realize several different schemes.
...
cycle 1 period
cycle n
Figure 3: Job scheduling states and times All the release times (earliest start of...) are handled by the event service. It is the responsibility of this service to trigger the delivery of a job at the requested time. This includes single job delivery as well as an automatic periodic delivery with a given cycle time. Furthermore, the event service monitors all the deadlines (latest end of ...). If a deadline is violated, the event service reports an error. Note, that all times are optional. So a simple event service may not support all of the times or actions (e.g. no periodic actions) and thus saving memory. The QoS report function of the event service is responsible for providing this information.
4. An Application Case One of our application cases is the development of a distributed measurement and control systems for the oil drilling industries. This project is a cooperation of several European partners and is funded by the EU. In order to enhance reservoir exploitation, a better management of wells can be done through the use of the permanent real-time monitoring and control techniques. Data like oil pressure, temperature, flow, density, etc. is periodically collected over packet-switched communication links by sensor networks placed in all wells within production fields. According to the collected data automatic reactions like opening and closing valves are computed in real-time.
3.4 Event service While the other basic services contribute in a more passive way to the overall real-time behavior
Figure 4: The oil drilling application
Figure 4 shows the overall architecture. Each well is equipped with a microcontroller responsible for the periodic real-time data acquisition. The acquired data is then evaluated in a central unit and requests for actions are returned to the microcontrollers. In a future extension, several central units for different oil fields shall be combined, e.g. to detect global events like earth quakes. So this is an ideal application for a real-time middleware. However, due to the location in a drill, there are several constraints regarding the microcontrollers: • the embedded electronics should be as light and efficient as possible, • since the operating environment is harsh (high temperature, high pressure), the power dissipation of the microcontrollers must be minimized, • the available room is restricted by the casing of the drill. This leads to the following basic requirements: • use a simple (not very powerful) microcontroller • keep the memory as small as possible For the first prototype implementation, a 12 MHz 80251 with 128 kBytes memory has been selected as microcontroller. The central unit is formed by a standard PC. For the microcontrollers, the CMX [5] real-time operating system is used, while the PC works with a standard Windows NT 4.0. While traditional middleware is not very suited to fit on a 80251 microcontroller, one main focus of our research is to find out how the OSA+ approach scales. Therefore, we are currently working on two implementations: a reference implementation without middleware and an implementation using OSA+. Figure 5 shows the OSA+ version. By comparing the two implementations we want to determine the overhead and the benefits of the middleware. Central Unit
Controller 1
Controller n
OSA+ Platform
OSA+ Platform
OSA+ Platform
Sensors
Actuators
Global virtual OSA+ platform
Sensors
Central unit: - normal PC
Actuators
Controller: - 12 MHz CPU - 128 Kb RAM
lot of debug and test routines, but it shows a trend. The 80251 version is not finished yet, but from work on the reference implementation without middleware we have experienced, that the Keil C compiler [6] produces smaller code for the 80251 than Visual C++ for the Pentium. Furthermore, the TCP/IP part of the communication service is not necessary and the process service will become simpler, because only threads and not heavy weight processes will be supported. So an overall size of below 60 kBytes for the first prototype microcontroller version of the middleware including all necessary basic services should be possible. Component Size Core 60 kBytes Memory Service 1 kByte Process Service 12 kBytes Communication 22 kBytes Service (TCP/IP) Address Resolution 5 kBytes Service Event Service 6 kBytes Table 1: Prototype memory sizes for OSA+ on the standard PC
5. Conclusions The approach presented here is still work in progress. But the first results look quite promising. Applying the microkernel conception to middleware enabled us to construct a first prototype with already small memory needs. Further work will concentrate on the following aspects: optimize the current prototype, port it to CMX and Java and evaluate the computational overhead introduced by OSA+. We want to take the optimized prototype as a basis to learn how to further reduce the size and overhead. Our goal is to go at least below 32 kBytes and thereby to introduce the advantages of middleware to the field of very small and low power systems.
6. References [1]
Figure 5: Implementation using OSA+ [2]
Some preliminary results are already available: besides the standard middleware benefits like hiding distribution and communications the periodic data acquisition is well supported by the periodic job delivery of OSA+ (see section 3.4). On the overhead side some memory sizes for a first prototype OSA+ implementation on the PC are given in table 1. This implementation has been made in C using the Microsoft Visual C++ compiler. It is not very optimal yet and contains a
[3] [4]
[5] [6]
Object Management Group: The Common Object Request Broker: Architecture and Specification. http://www.omg.org DCOM Architecture, Microsoft: http://microsoft.com/com/wpaper/#DCOMpapers. T.B. Downing: JavaRMI: Remote Method Invocation. IDG Books Worldwide, Februaray, 1998 Sun Microsystems: The Java Message Service API. http://java.sun.com/products/jms/index.html CMX: RT operating systems, http://www.cmx.com Keil: Software Embedded Development Tools for the 8051, 251. http://www.keil.com
