Keywords

1 Introduction

Embedded systems in an unpredictable and disturbed environment, like underwater control systems, have to take into account various situations by considering different strategies. Their development requires large parameters configuration in order to ensure safety and efficiency of the controlled system.

The configurable parameters are used to characterize the context (environment interpretation and its evolution), the execution platform and the control part of the system. The tuning of the parameters is based on simulations for cost reasons and on real testing for safety reason. At the end, the system has to be equipped with adaptation and/or learning abilities to adjust some parameters online. Therefore, there is a strong need for offline and online tuning tools. Unfortunately in industry, the development of the software for such systems is mainly focused on the code efficiency. The produced embedded code is dedicated to a given platform for a specific application in a specific context. The obtained code is difficult to maintain and to adapt for new applications and new contexts. Portability and reusability are limited.

To tackle these limitations, we propose in [1] a model-based software architecture integrating high adaptive capabilities, the IMOCA approach. Once the architecture model is established, a key point is then the code generation. In this paper, we present the implementation of the model-based code generator from the architecture model IMOCA. Even if the deployed code remains specific, we propose generic models of code generation to allow:

  • the control of quality and efficiency of the generated code: the code is optimized for static parts and modular for adaptive part;

  • the integration, and so the reuse, of existing specific legacy code is facilitated: domain functions such as control law, communication protocol, acquisition policy can be easily integrated;

  • the code generation for different target platforms: the architecture model and most of the code generator is independent of a given platform, specific aspects are encapsulated in a platform abstraction view;

  • the model and the code generator integrate testing, adaptation and tuning facilities: design facilitates declaration of adaptive parameters and functions, parameters can be tested with a generated simulator, code integrates reconfiguration capabilities for adaptive parts.

The generated simulator is written in Java, while the generated embedded code is written in C language (or family of C language). To generate optimized embedded code, the code generator is based on the principles presented in [2]. The models and tools have been tested on NXT bricks, Arduino boards and Armadeus boards for simple control applications, sand yacht control and autonomous sailing boat VAIMOS control.

After a presentation of the IMOCA architecture model, we present the structure and the underlying principles of the code generator while using it with two applications on two different execution platforms.

2 Related Works

Component-based approaches [3] for the conception of the embedded systems are relatively classical and allow to deal with the software complexity [4] and the well-known separation of concerns in Model Driven Architecture (MDA) terminology [5]. In particular, software evolution ability in order to take into account either the platform maintenance or system behavior adaptation or parameters tuning [6] can be viewed as software flexibility [7]. Generally, efforts to increase the flexibility lead to conflicts with respect to the material resources of the execution platform [8]. In [9] binding each component to an adaptation policy allows software evolution, but this solution assumes that the evolutions are predictable. [2] tries to conciliate the software evolution at run-time with the hard resource constraints of the embedded platforms. Relying on this work, we focus on the conception of domain-specific models of components (we focus on a specific domain without modeling specific features of the components), then we generate optimized code which embeds the necessary elements for the reconfiguration [2].

3 The Architecture Model IMOCA

IMOCA for archItecture for MOde Control Adaptation is an architecture model dedicated to the development of process control systems embedded in a disturbed environment. This architecture is composed of three layers called Target, Interpretation and Control (see Fig. 1). Target with its Actuators and Sensors is a platform-specific model of I/O. Control uses Data (an ideal view of the environment) to compute ideal Commands to act on the environment. The Interpretation layer realizes the adaptation between the Target layer and the Control layer by linking Sensors and Actuators on the one hand, to Data and Commands on the other hand. In this way Control and Target are independent like in SAIA [10] and this allows the development independently of specific sensors and actuators technologies. This independence is important in the context o f embedded systems because material platforms may be various and may evolved (change or add a sensor for example).

Fig. 1
figure 1

Principles of IMOCA approach

Full size image

The Controller is composed of three sub-controllers. The Reactive Controller applies a control law to compute a Command from Data. The ExpertController is in charge of defining the current control law. It is based on a finite state automaton that manages running modes. Each state is associated with a Mode which is itself associated with a control law. A state change is linked to a change of state of the environment (a function of Data which returns a boolean). Finally, an AdaptativeController adjusts different parameters of the control law with respect to a look-up table in which appear all the possible Configuration. Based on this three collaborating controllers, the Controller allows to answer the three following requirements: controlling the process with the ReactiveController by applying an adapted control law thanks to the ExpertController, and finally, adjusting the control laws with respect to the context in order to keep a high quality of control with the Adaptative Controller.

4 Code Generation

The model of the software architecture design is an instance of the meta-model IMOCA, expressed using ecore. The code generator leans on Acceleo technology which allows to define code generation principles through an Ecore meta-model.

4.1 Parameters Configuration

A software application based on the architecture model IMOCA integrates variability to adapt the system to a specific context or a specific platform. Variability is first implemented through parameters to characterize, for example, a threshold in a filter adapter, or a coefficient for a control law. Second, the ExpertController automaton defines a dynamic behavior through running modes. To tune parameters and modes, we propose to generate simulation tools to evaluate the impact of different parameter values and actions on the system.

In this paper, we target the generation of an adaptive and reconfigurable embedded code. “Adaptive code” means the application is able to take into account the evolution of its environment through the adaptativeController. For each environment context, specific values of parameters are defined at design time using the simulation. Then, the adaptativeController adapts online the values depending on the context. “Reconfigurable code” means that the embedded values of the parameters can be modified online without the need to recompile the code. The reconfiguration capability concerns parameters only, the architecture of the application cannot be modified online.

In this version, a Java simulator is generated. The generation of this simulator is based on high-level data (sensors and actuators are not considered here) and includes all the controllers. The designer can test different control laws and parameter setting through a dedicated generated User Interface. Each Data can be controlled and each new Command is printed on a control screen. To view the real effect of the controller, it is necessary to implement an environment simulator for the system itself (as in [10]). The latter must be connected to the commands sent by the generated simulator.

4.2 Taking into Account the Behavior

The architecture model IMOCA is a declarative model. It allows to focus on specific features of the target application (activation periods, number of operating modes, ...). However, IMOCA is not a programming language, the expected behavior is not described explicitly. The expected behavior is implemented by the code generator, following the IMOCA semantic.

For this purpose we distinguish two parts. The former corresponds to the operational semantic of IMOCA which has been given in the previous section. The code generator is directly in charge of this part. The behavior is expressed in a simple C code (no pointer) to be reusable in different languages. The latter is specific to application-dependent part and is encapsulated in domain-specific libraries. The code generator is in charge to produce glue code to link these two parts via a simple library integration.

According to these principles, the ExpertController and the adaptive Controller automata are generated together with a general controller and the code dedicated to Data and Command. For the Sensors and the Actuators, the Interpreters and the ReactiveController, only the declaration and glue code is generated. To complete the code, the user provides specific libraries to deal with sensors acquisition (filters, ...), actuators management, Interpretation and control laws.

As an example, the generated code presented Fig. 2 defines the expert controller of a mini sand yacht and is, in fact, the implementation of a finite state automaton. Each state change is bound to the evaluation of the data theta which represents the heeling of the sand-yacht in degrees. For information, here we have three states (states 1, 2 and 3) respectively corresponding to a normal state, a (excessive) heel to starboard and a heel to port.

Fig. 2
figure 2

Code of the expert controller

Full size image

4.3 Domain-Specific Code Integration

As previously said, generated code must be completed by adding domain-specific code. Since many dedicated libraries exist, the idea is to generate code in a way that allows a smooth integration. As in a component-based approach [5], IMOCA produces a set of signatures of functions for all relevant components (sensors, actuators, filters and reactive controller). Thus, the designer has to provide the set of corresponding implementations (user code) while respecting the static typing. In addition, we use the properties of Acceleo to add, in the generated code, portions of customizable code. For this purpose, a special place is pointed by a commentary and is available for the user (see below). By default, a code is provided which can be modified and completed. It should be noted that subsequent generations of code take into account these changes (automatically performed by Acceleo). This default code calls a user function for each domain-specific component, user function to be implemented.

figure a

If the user keeps the call of the specific function, he must provide a function that respects the signature required by the code generator to the specific library:

figure b

4.4 Taking into Account Platforms

In order to address various execution platforms, we need to generate specific code for each of them. However, a significant part of the code generator must remain generic and independent of the target language. For example, the behavior of the ExpertController is independent of the target language.

To address this requirement, the code generator is based on three software layers. The first one is concerned with generating the specific behavior related to IMOCA. It can generate imperative code or object-oriented code. We add a parameter to each generative function to define the expected code (imperative or object-oriented). The second layer is based on the first one and is specific to the target language (Java or C for example). It is in charge of generating the files respecting the specific language features for the declaration of files, classes or functions. Currently, the specificities of the executive are included in the second layer via the definition and the call of tasks. The last layer is in charge of general services.

For the first version of the code generator, the target language is based on the basic constructs of C language (assignment, control structures). Pointers are not used. Thus, we can rely on this layer to generate C, C++, Java code or any C-like language.

We have used the code generator for two applications deployed on different platforms. The former is a NXT Lego brick equipped with a motor and a touch sensor. We just control the speed of rotation of the motor by using the touch sensor. The latter is a mini sand yacht with an Arduino board Mega and an inertial motion unit (IMU). We have to try to keep the course and, in the same time, to avoid the capsize of the vehicle due to the wind action.

At the level of second layer, the first part of the code presented Fig. 3 allows to generate the file Input.nxc whereas Fig. 4 presents the same thing for the simulator (some lines of commentary have been removed).

Fig. 3
figure 3

Fragment of the generateInputOutputNXC.mtl Acceleo module

Full size image

We generate NXC source code for the NXT platform. NXC means Not eXactly C, a C-like language with some specific features. Generated files have an extension of nxc (here the files are Input.nxc and Output.nxc) and we retrieve the preprocessor invocations like in C. We include only implementation files, because NXC does not h integrate interface files. Each data needs a declaration, the definition of their attributes (value, frequency, format ...) and of their access methods.

Fig. 4
figure 4

Fragment of the generateInputOutputJava.mtl module

Full size image

The equivalent Acceleo code to generate the simulator (see Fig. 4) produces Java code. A Data is viewed as a high-level data, that is to say here as a class. However calls like [generateWriteDefinition(data,0)/] remains identical to those used to generate code for the NXT brick.

In the first layer, Acceleo modules are parameterized by the type of the used language (0 for object-oriented programming, and 1 for imperative programming). Figure 5 shows this case.

Fig. 5
figure 5

Acceleo template for generating object-oriented and imperative code

Full size image

This leads for the case of the NXT brick (the commentaries have been removed) to:

figure c

whereas the generated Java code is:

figure d

4.5 Structure of the Code Generator

The code generator is modular with a set of specific modules for each component of IMOCA. For the first and second layers, a code generation module is proposed for each modeled entity (Sensors, ExpertController, ...). Utilities modules are used to complete the code generator in order to factorize and simplify common pieces of code.

For the first layer, simple components (ReactiveController, Sensor, Actuator and Interpreter) are built according to the same principles. A class (or a structure in the case of imperative code) is generated which manages objects (or structure) that contain typed data, an initialization function, a configuration function, a getter, a setter and specific executive functions (a “run” for each filter and for each control law of reactive controller). The other control components are generated through a specific function which implements automata. Other components implement a service layer (to respect the Facade Design Pattern, a main program (the main) and communication tools (to implement communication with a remote client in charge of reconfiguration).

Figure 6 shows a piece of Acceleo code which stands in the first layer of the generator and concerns the Data.

Fig. 6
figure 6

Fragment of the generateDataUtils.mtl Acceleo module

Full size image

To assist testing, the generated code is also modular. For object-oriented language, a class is generated for each element (each sensor, each data, each controller, ...). For an imperative language, a file is generated for each element. Thus, the structure helps on unit testing activity.

4.6 Reconfiguration

The code generator generates reconfigurable code in the sense that parameter values must be changed online. To prepare the code generation, each parameter can be recorded as reconfigurable (the value of the property IsControllable which is false by default, is set to true). If at least one reconfigurable parameter exists, a client interface (currently in Java) is generated to allow the tuning of the values of reconfigurable parameters. In the embedded code, a server task retrieves the changes and modifies online the corresponding parameters (this modification is done via a call to the corresponding setter). This tool is especially useful during prototyping phase. The behavior of the system can be tested without having to stop and recompile the whole application [2].

5 Conclusion and Future Works

This paper presents an approach to generate adaptive and reconfigurable embedded code based on the architecture model IMOCA. The code is designed for process control systems in disturbed environments and can be generated for different platforms. A Java simulator is generated to assist the user in the tuning of control laws. The case of an NXT robot and a mini sand-yacht equipped with an Arduino board have been used for experiments.

We are working on addressing other platforms and on optimizing the code to take into account limited platforms. We also seek to control the consumption of autonomous systems, like drones, by using control policies based on energy criteria. Finally, we seek to enrich the integration of existing specific libraries to deal with other application areas.