Safe Virtual Machine for C

Altreonic is new releasing v.1.4 of its breakthrough formally developed network-centric OpenComRTOS designer suite. It acts as a Virtual Machine or type 1 (in essence a hardware abstraction layer) for the applications tasks.

Altreonic’s Safe VM is made available to the developer as an VirtuosoNext or OpenComRTOS task that has the capability to execute binary C code in a platform independent way. Any processing node in an application can have multiple Safe VM tasks. Each of them can access the underlying hardware and interact with other natively running tasks using the available RTOS services. Yet the latest version of the Safe VM only requires 2838 bytes for program and 476 bytes for data. (measured on ARM Cortex M3). While the Safe VM itself is written in C, the code itself was automatically generated from a higher level description. A first model expresses the instructions and their actions of the Virtual Machine; a next level refines this into lower levels commands while the lowest level represents the finite state machine of the VM. The VM itself is generated as optimized C code. This approach guarantees that the VM is correct by design, is close to optimal and allows using more elaborate VM instructions set a redefinition of the models. It also allows adding safety support (e.g. acting like a software MMU on bare bones processors.

Another application of the Safe VM is to execute legacy binary code on a more recent processor. This requires a redevelopment of the VM for the particular binary target.

SVM apps

What Altreonic’s Safe VM does is bringing the power of “apps” to the embedded world. Users can create an SVM task and download it to a running embedded application, on any properly set up node in the system. The Safe VM task can use any service of the natively running RTOS system, yet it requires only Kbytes of memory.

A new application domain for the Safe VM is the capability to run old binary C-code. While it requires to generate a new Virtual Machine and has some restrictions like hardware dependencies, it allows to save previously developed software.

Safe VM 1: System diagnostics.
During the development of a system, different integration tests have to be performed, including user testing.
The diagnostic data gathered can be different for each of the test runs. For instance, during test run 1, the tester will look at the current peaks, while for test run 2, the tester will look at the evolution of the voltage level of the DC bus. For each of the test runs, the tester can simply download a dedicated diagnostic Safe VM app on each of the processors, without having to change the core components of the system. This also means that the test is not intrusive and can all tests can fit in the available memory.
After a test run, the gathered diagnostic data is communicated directly by the Safe VM task into the test database hosted on a laptop hooked up to the system.

Safe VM 2: Reusable system components.
When developing system components it would save time and resources if the development team would be able to easily configure a complete system based on its unique characteristics).
For vehicles for example, motor, generator, traction controllers and the energy distribution system will vary from vehicle to vehicle/ One vehicle might be a full electric, using a synchronous motor, a gear box and a battery system. The system is then configured with the Safe VM app for the synchronous motor, the gear box and the battery system. Another vehicle might be a diesel hybrid, using a diesel engine, a generator, two wheel motors. The system is then configured with the Safe VM apps for the diesel engine, the generator, and 2 motor controllers.
The reusable components are coded in C, and can be deployed on all VirttuosoNext or OpenComRTOS nodes, giving integrators different options for the ECU of the system. If different ECUs are used together, it is also very easy to reconfigure the multiple tasks over the nodes, for efficient use of the capabilities and connectivity of each of the nodes.

Safe VM app 3: Insurance or fleet component for driver or operator profiling.
Insurance companies or fleet owners want to control the driving behavior of the drivers. With Safe VM apps, these companies can install a dedicated app to monitor a set of signals like vehicle speed, wheel speed, brake control parameters, motor temperature, output from accelerometers, etc. If these parameters signal driving patterns that fall outside standard behaviour, this can be detected and an investigation started te prevent further safety of monetary risks.

Safe VM app 4: System statistics.
An operator can add Safe VM apps to log certain ownership aspects of its system, like information on maintenance interventions, energy consumption, operational use,etc.
Back at home, the app can send its data to the home network, or to a smartphone. With a companion app on the smartphone or tablet, the system's owner can manage the total cost of ownership and plan maintenance actions based on the statistics.

Safe VM app 5: Load balancing.
As a safe VM app can run anywhere, it can be used as a generic component that travels in the target network while collecting data on resource usage. Communicating with a monitoring program on a host node, a load balancer can then reconfigure the workload based on a predefined criteria. For example, the data to be processed can be redirected to nodes with a lower workload of with more processing capacity. Or processing nodes can be put in a higher speed mode until the workload peak is over. This allows the load balancer to optimise the system globally which is not possible with algorithms thaht work locally only.

Safe VM app 6: Fail Safe operation by redundancy.
When some component fails on a processing node, a Safe VM app can be downloaded or activated (when already present) to provide a reduced but safe functionality. This allows the application to continue even if in a degraded functionality mode.

Safe VM app 7: Executing legacy binary code.
A new application domain for the Safe VM is the capability to run legacy binary C-code. While it requires to generate a new Virtual Machine and has some restrictions like hardware dependencies, it allows to save previously developed software, even if the original source code is lost.

Future Sage VM app: jumping Safe VM app.
Some (future) assumptions:
-    VirtuosoNext and OpenComRTOS applications can move SVM tasks without user intervention…
-    SVM tasks can store data linked to the task, that can move together with the task…

When multiple systems with support for “jumping safe VMs” connect in a larger system of nodes, interesting things can happen.
A jumping app can travel from one system to the other. On each system, the app can connect to local components and communicate at high speed.
The jumping app can aggregate data and take the data when traveling to the next node.

Example: The diagnostic apps of above will travel to each of the ECUs without user intervention.
The core components on each of the RTOS ECUs provide a similar diagnostic interface. When the diagnostic app lands on an ECU, it starts to communicate with the local components to gather and aggregate info. When finished, the app moves to the next ECU. If the system is the “dashboard”, the aggregated info is displayed or can be downloaded to a database. The advantage of a jumping app in this case is that special ‘diagnostic apps’ can be installed in a car, for instance before testing or maintenance trips. If a car has some special problem that needs to be diagnosed, the service personnel can ‘load’ a special diagnostic app in the car and start a test run. The jumping app will travel to each of the ECUs and search for the problem, maybe involving some artificial intelligence…

Another application example is automatic load balancing and redundancy.
When all important functions of a system are coded as jumping Safe VM app, the complete system can automatically move tasks based on the current load and current state of connectivity between the processing nodes. For instance, if a certain link from a node to a sensor fails, and a backup link to another processor exists, the system can reconfigure to move the sensor monitoring task to the other processor. Or if a certain task suddenly consumes a lot more CPU cycles, the system can move it to a node with more CPU power.