Platform Integration Aspects: Certification Aspects

Appliances do often have the requirement to be certified prior to a deployment to a dedicated market, e.g. the market for medical products. This article shall give you a short guidance about the topics to be kept in mind when it comes to certification related to products which are equipped with an Embedded Wizard powered GUI.


The Embedded Wizard technology itself can be seen as a so-called Software Of Unknown Provenance (SOUP) as described within ICE 62304, whereas the hotspots are the Embedded Wizard Platform Package and the Embedded Wizard Code Generator. Due to the fact that the GUI code itself is developed within your project, it belongs to your software development process. Your process must be aligned according to the requirements of the applicable standards.

How to categorize Embedded Wizard?

Embedded Wizard is a commercial product and Embedded Wizard driven GUIs have been deployed with billions of devices for the past decades. Embedded Wizard comes with a full and sophisticated documentation, release notes and a proper life cycle management. However, within your own project's life cycle, you can decide whether you want to stay on the same Embedded Wizard version or not. If you have licensed the so-called Professional Edition of Embedded Wizard, all target related software used within your project is available as source code. This means, no additional audit for a software development process of hidden code, like code provided as library, is necessary. Besides of this, Embedded Wizard is generating pure ANSI-C source code, which is well proven with various compilers on various platforms. Because Embedded Wizard GUIs are mainly suited for resource constrained systems, we highly optimized our stack accordingly, knowing that those optimizations do explicitly not fulfill all requirements of the MISRA-C standard.

Risk Analysis

For certain certifications a risk analysis of the different software parts must be prepared. It is important to detect the 'level of confirm' for the GUI part of your product. Here we recommend to take care on the following aspects:

1.Dynamic Memory Management

Within Embedded Wizard a dynamic memory management is used to dynamically allocate the required memory for e.g. object instances and GUI resources. During development the memory usage can be monitored on the platform to analyze the memory consumption of your GUI. But even if there is more dynamic memory available as you detected as a memory peak, the fragmentation of the memory pool can also cause an 'out of memory' fault. Within the Embedded Wizard Platform Package, this is detected and the function EwPanic() is called. Within your project code you have the possibility to modify this function according to your requirements.

2.Infinite Loop Detection

A further typical problem which might occur while implementing a GUI is an infinite loop or a huge processing load which causes that the GUI does not respond to user interactions within an expected time frame. Such a behavior can be caused by endless loops or recursive calls, even via multiple instances. To detect this, it might be helpful to add a watchdog for the GUI process itself.


Now what can be done in the above scenarios 1 and 2? For most products containing a GUI part it is important to present the current system state to the user and to allow interaction with the system via the GUI. Whenever the GUI part of the product reaches an undefined state it should be possible to restart the GUI. After restarting, the GUI shall present the current or at least the previous system state which is - in the best case - the identical display content as before the restart took place. This can be reached by keeping all relevant system states within the middleware layer, including at least the current screen presented by the GUI. After restarting, the GUI will get this system state and present the related screen accordingly. If the restart of the GUI takes e.g. 100ms, it might be an acceptable behavior for the product in such a very unlikely situation.


Please be aware:

The Chora language is very strict. The support of potentially ambiguous or even dangerous language elements is limited. Open arrays, pointer arithmetic and implicit data type conversion popular in other languages like C++ are completely absent in Chora.

The memory management of Chora is based on a garbage collection. It detects unused memory and releases it automatically. The classic errors such as the access to already released memory or memory leaks are excluded.

As a result, the generated source code that will be part of your product is very reliable and stable.