Altreonic News Q1 2010-1

1. Meet us at Embedded World 2010, Industrie Messe, ESEC, ERTS2

remaining items available from here: [1]
2. New Company Profile
3. Asynchroneous services for OpenComRTOS
4. Ethernet support for OpenComRTOS
5. Latency demo shows OpenComRTOS real-time determinism
6. Enhanced OpenTracer
7. Session based host services
8. OpenCookBook analyses dependencies

1. Meet Altreonic at Embedded World 2010, Industrie Messe, ESEC, ERTS2

2. New Company Profile

[6]From Deep Space to Deep Sea, Push Button High Reliability.

This is our company's moto and driving force. Achieving it is a big challenge but Altreonic has already the methodology and has most of the supporting tools in place. At the core is a mindset and a vision that is universal but still powerful through its simplicity and focus on embedded systems.

Unified semantics, interacting entities, formal methods, modeling, real time distributed processing, safety standards are keywords that we put in practice for a safer and more sustainable world.

Trustworthy = safety + security + privacy + useability.

Keep it Simple but Smart.

3. Asynchroneous services for OpenComRTOS and OpenVE

Being formally developed, OpenComRTOS benefits from the flexibility offered by the Hub interactions. Often the developer sees them as the traditional RTOS services (events, semaphores, fifo's, resources, etc.). From a programmer's view these services allow tasks to synchronize and to communicate in a synchroneous way. In OpenComRTOS, these are called single-phase services. However, tasks often want to interact in an asynchroneous way. In an embedded system this is failure-prone as resources are strictly bounded. The OpenComRTOS solves this issue and actually allows feedback on success or failure of the interaction.

The asynchroneous services are a unique type of service as they operate in two phases. In the first phase the application task (or driver) issues a request to synchronize or pass on data via an intermediate hub entity. This request is non-blocking and hence the task can continue. Later on it can wait for the confirmation that the sysnchronisation or data exchange has happpened. A task can simultaneously have multiple open requests using one or more hub entities. This is valid for sending as well as receiving tasks and provides a very flexible and efficient mechanism. Safety is assured by the use of a credit system.

Each task starts with a number of credits. At each synchronization request, the credit count is decremented and  when synchronization is confirmed, the credit count is incremented. As asynchroneous services use dynamically allocated resources (associated with the credits), this assures that the system remains predictable. If synchronization is not reached, the sending task is informed that the processing has encountered a problem at the receiver side and vice-versa. The application will however not halt or crash and corrective action can be taken. Note that the OpenComRTOS implementation only uses a few 100 bytes of extra code and data memory for providing the asynchroneous services. All requred memory is determined a well at build time.

The asynchroneous services greatly increase the flexibility for the programmer while keeping the program fully predictable. It can be used e.g. to exchange data between tasks that operate at different rates or even more important it provides tasks with external choice. Sending tasks can send their packets to different hubs and receiving tasks can receive from different hubs. As a result, synchronization is no longer tied to a specific execution order and tasks can wait on multiple events or communication exchanges.  Contrary to many other approaches no malloc's are involved and  use of memory resources is constrained.

The asynchroneous services are in particular very handy to interface Interrupt Services Routines (ISR) and driver tasks. An ISR is driven by hardware interrupts, whereas driver tasks might need to execute a protocol along different execution paths and can be preempted.  Using  asynchroneous Packets, both sides are decoupled through the intermediate hubs while a driver task will only run when data is available. Asynchroneous services are now introduced supporting local Port hubs. In an upcoming release, the mechanism will be made available for other hubs as well, even when distributed across the nodes.

  Example code:
 
 //sender side:
 
  L1_SendPacket_A (*Packet, Hub);

  .... do something else

  L1_WaitForSync_WT (Hub, p, T);
 
  // receiver side:
 
  L1_ReceivePacket_A (Packet, Hub)  

  .... do something else
  L1_WaitForSync_WT(Hub, p, T);

4. Ethernet support for OpenComRTOS on ARM-Cortex-M3

An important advantage from the network-centric and formal design of OpenComRTOS. is that ISRs, Hubs and driver tasks can physically be distributed in a transparent way over rmultiple processing nodes, allowing better performance and less latency.
OpenComRTOS' architecture supports such multi-processor architectures at a very fine grain level of concurrency, removing the software barrier to efficiently using such multi-core architectures. While OpenComRTOS can support processor networks with almost any type of interconnection  technology, this is a challenge because there is a diversity of hardware. In addition, often the hardware is not designed to cope with failures. Ethernet doesn't seem to suffer from these inadequacies but requires more hardware and software resources and is less suitable for lower end processors or for physically tight connections. When using ethernet as a LAN technology, there is also the issue that any hard real-time capability disappears and worse,  performance doesn't scale any longer when the network starts to get loaded.

A major advantage of ethernet (and TCP/IP) however is that it is very robust communication protocol as internet proves us everyday. A way to have the best of both worlds, is to use ethernet in a point-to-point connection scheme. This is fully compatble with most embedded systems and allows an easy way to connect through a host node with the internet. This also means that not a full TCP/IP stack needs to be implemented.

5. Latency test shows OpenComRTOS real-time determinism

Although embedded systems heavily depend on concepts like interrupt latency and the notion of real-time, people will often give them different interpretations. Altreonic's notion is that real-time means predictable. As embedded software runs on sequential processors and communication links are often shared resources, predictability is implemented using prioritisation at runtime. Essentially, assure that any task with a higher priority runs first. Performance is achieved by a careful design of the kernel and the use of preemption. In OpenComRTOS we apply the same principle by using priorotised packet switching at the communication layer.

The hardware can however override this preemption when interrupts happen, triggering the execution of Interrupt Service Routines (ISRs). Hence, it is paramount that ISRs are kept as short a  possible to minimize interrupt latency. If not, other interrupts will be delayed. To make it realistic, we define interrupt latency as the time interval between the moment the hardware interrupt occurs and the moment the application can read the data. In a test set-up, this is achieved by using a programmable timer and by reading out the timer value. In practice this interrupt latency will never be a single figure. It depends on what the simultaneous occurrence of other hardware interrupts and  on what the  software was executing at that moment. Important is that the latency is strictly bounded. Hence the latency is statistically distributed that should show maximum values with very low probability with no outliners (like a Poisson distribution).

On a 50 MHz ARM Cortex-M3 we measured the latency in the ISR and to a high priority task. The following figures were obtained on a stress test loaded processor (continuously performing context switches using a semaphore loop).

- Interrrupt-to-ISR: between 300 nanoseconds (typical), 2420 nanoseconds worst case

- Interrupt-to-Task:: between 13  and 32 microseconds worst case.

This data clearly shows that performance can benefit from the formal development process that was used for OpenComRTOS. Small code size still translates in better performance.

6. Enhanced OpenTracer

Concurrent real-time applications can sometimes be difficult to understand (especially when things seem to go wrong) because the scheduling is dynamic and distributed. Therefore Altreonic developed OpenTracer which acts like an oscilloscope for real-time software.

The latest version has been largely redeveloped reducing the tracing overhead in the kernel, but especially facilitating the tracing of inter node interactions. This is less trivial than many people think because each processor runs at its own clock speed and multiple communications can pass through the same node. Therefore we introduced sequence numbers allowing to track task and node interactions across space and time. Although OpenComRTOS uses system wide priorities, even in the communication layer, each processing node schedules tasks in order of the local priorities and interactions can be delayed because they originated from lower priority activities.  OpenTracer facilitates finding order in these numerous interactions.

7. Session based host services

One of the interesting benefits of OpenComRTOS is that any node, even when limited in memory, can easily access services on a host node.  This works by instantiating a hostserver task on the hostnode. On the client node, the developer just links in a library and calling the services is transparently supported in OpenVE. This is typically used for stdio services and graphics.

The new release of the Graphical Host Service is now session based. This makes it easier to share the canvas between multiple tasks and nodes, because it avoids the need to perform the session handling on the client side. Furthermore, it results in serious speed-ups, because the previously necessary synchronisation protocol between the clients is avoided.

8. OpenCookBook analyses dependencies

In any project it is always a challenge to find out the impact of changes.in a project. A requirement change can result in having to redevelop, retest or revalidate already developed components. On the other hand a failed test can mean that the requirements and specifications have t be re-examined or that the architectural design has to be modified. In general this is called tracebility and together with configuration management it plays a major role in safety engineering

OpenCookBook now supports the generation of dependency and precedence trees. This allows to analyze the dependencies from early top-level requirements down to the final release along all steps in the development process. Vice versa, the precedence tree generator allows to trace back e.g. changes in the validation or test tasks to the original requirements and specifications.

Another addition was to integrate OpenCookBook with TaskJuggler. Tasks defined with their resources in person-effort and time can be exported to Task Juggler, an open source project management tool. Other improvements are a new document generator and the capability to host multi-project portals. The current release of OpenCookBook is still abased on the open source drupal CMS and can be freely downloaded from our website. It can be installed on a webserver (dependencies are Apache, php and MySQL) or installed locally an a PC (using e.g. the WAMP package).

Altreonic nv
Tel.: +32 16 202059
Web: http://www.altreonic.com [6]
Email: info request @ altreonic.com [7]