As illustrated in the picture, a typical TASTE Application is composed of the following layers :
- The Application layer
- The Glue Layer
- The Middleware
- The OS with BSP support
The Application Layer
The application layer is the application code for the application functions to be performed by the system. This is the code of the user, written either via application models (SDL, Matlab/Simulink) or via a regular programming language (Ada, C, ...). The application layer is basically a set of functions - written by the user - that interact with the automatically generated functions in the application skeletons that are generated from the TASTE Interface View.
The Glue Layer
The Glue Layer is generated by buildsupport and connects application layer code and data with the lower parts of the system.
- The glue layer generates resources (tasks, buffers, data) to connect application functions so that user functions can interact with the other parts of the system (other functions located either on the same or a remote node).
- It also uses the run-time data structure translators (automatically generated by the DMT Tools) that convert data back and forth, between ASN.1 and C/Ada/SCADE/Simulink/RTDS/etc - thus allowing any function to talk to any other.
- Finally, it injects values produced from the application in the middleware and retrieve values from the environment and put them into the system when needed.
The middleware layer consists in interfacing the glue layer with the underlying Operating System and BSP functions. To do so, it adapts the application code and the glue layer code to be compiled and executed with the target environment (hardware and operating system).
One example of the middleware function is to adapt to several operating system using different primitives. For example, when the glue code creates tasks, the function called to create the tasks would be different, either you are executing your system under Linux or RTEMS : if you are using Linux, you will call pthread-related functions (such as pthread_create) whereas on RTEMS, you would use rtems_task_create and rtems_task_start. To overcome adaptation concerns, the middleware layer provide unique functions to create resources (for example __po_hi_create_task()) that performs appropriate calls regarding the target operating system (Linux, RTEMS, Ada runtime, etc ...).
The middleware layer is composed of two parts:
- A generated part is produced from models of the system requirements. This part is automatically generated from the Concurrency View (generated itself as AADL models by buildsupport) with Ocarina. This parts generates taks, buffers, call to initialize drivers, etc. according to system requirements (drivers to be used, tasks to be instantiated to executed the application code, etc.)
- A static part that contains generic primitives to adapt the generated code to the target environment (OS and BSP functions). This parts consists in providing wrapper functions that would be called to adapt the user code to the target environment.
TASTE can be used with two runtime :
- PolyORB-HI-C, a C runtime that is officially supported by ESA
- PolyORB-HI-Ada, an Ada runtime that is Ravenscar compliant and can be used on top of Ada runtime (such as ORK)
OS with BSP Support
The OS with BSP support is the target execution environment. It is the Linux operating system that executes your application or a specific version of RTEMS with some dedicated special driver. The OS is reused as-it, meaning this is not provided specifically by TASTE. However, as TASTE adapts itself to the underlying OS and BSP functions, the underlying OS and BSP functions have to be supported by TASTE. At this time, the platform supports many OS such as Linux (with or without real-time capabilities such as Xenomai), RTEMS (4.8 and 4.10), etc.