Difference between pages "COMPASTA: Integration of the TASTE and COMPASS toolsets" and "TASTE Step by step tutorial"

From TASTE
(Difference between pages)
Jump to: navigation, search
(Analyses Reference Guide)
 
(Hello World)
 
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
COMPASS is a tool for model-based system/SW co-engineering developed in a series of ESA studies (2008-2016). It offers a complete set of functionality for formal verification, including requirements specification and analysis, contract-based design and verification, functional verification, fault specification, fault injection and RAMS analyses, including Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA), Diagnosability Analysis, Fault Detection, Isolation and Recovery Analysis (FDIR). The COMPASS engines, providing formal verification capabilities, are based on model checking.
+
This tutorial explains how to quickly build a system using [https://taste.tools/ TASTE].
  
COMPASTA integrates the COMPASS functionality into TASTE, thus providing a comprehensive, end-to-end tool chain that covers system development, early verification and validation, safety assessment and FDIR, and system deployment.
+
Make sure you have either installed the TASTE Virtual machine : https://download.tuxfamily.org/taste/TASTE-VM-10-64bit.ova
  
:[[File:ClipCapIt-221111-102354.PNG]]
+
...or that you made a manual installation following the instructions here: [[Manual installation on a native platform]]
  
 +
If you use the VM, note that the username and password to login are taste / tastevm
  
In summary, the COMPASTA workflow can be described as follows:
+
= Important =
* COMPASS is used to build and validate a formal model of the system (including both HW and SW) architecture, to specify the behavior of the HW components and their faults
 
* TASTE is used to model the behavior of the SW components, for deployment and code generation, and to test the final implementation
 
  
Specifications in COMPASTA are based on the AADL and SDL as specification languages AADL is used for the interface view and for the specification of the behavior of the HW components. SDL is used for the specification of the behavior of the SW components.
+
Always make sure you are using the latest version of the TASTE tools.
 +
From within the TASTE Virtual machine or your native installation, open a terminal and run the following commands:
  
COMPASTA verification engines comprise:
+
  $ cd tool-src
* the nuXmv model checker [https://nuxmv.fbk.eu/]
+
  $ ./Update-TASTE.sh
* the xSAP safety anaysis platform [https://xsap.fbk.eu/]
 
* the ocra tool for contract-based design and refinement [https://ocra.fbk.eu/]
 
  
:[[File:ClipCapIt-221111-155825.PNG]]
+
When it is done, close the current window and open a new terminal.
  
= Installation =
+
= Hello World =
  
COMPASTA can be installed on a Debian 10 or Debian 11 Virtual Machine. Installation within the VM requires the user to clone the taste-setup repository (branch compasta_feature_bullseye) and install TASTE as follows:
+
This tutorial explains how to create a basic system to get familiar with the tool.
  
    $ git clone https://gitrepos.estec.esa.int/taste/taste-setup.git tool-src
+
== Create a new project ==
  
    $ cd tool-src
+
Run the following command:
  
    $ git checkout compasta_feature_bullseye
+
  $ taste
  
    $ ./Update-TASTE.sh
+
You will be prompted for a project name and a new folder with this name will be created. Always use the '''taste''' command to re-open an existing project.
  
Further installation instructions will be added when COMPASTA is publicly released.
+
The Space Creator editor will show up:
  
= COMPASTA Workflow =
+
:[[File:ClipCapIt-221116-133346.PNG|1000px]]
  
We illustrate the COMPASTA workflow on the following example of a redundant power system. In this example, generators are used to charge batteries, which in turn power sensors. The lines connecting generators, batteries and sensors are redundant, and can be re-configures in case of faults. HW component may be subject to the following faults: faulty generators and batteries do not provide power, faulty sensors do not provide valid outputs. Two FDIR components control system re-configuration in case of faults, acting on the corresponding switches they are connected to. The system is operational if sensors are powered and provide valid outputs.
+
== Build the system logical architecture ==
  
:[[File:ClipCapIt-221111-103947.PNG]]
+
In the main window, draw a rectangle while pressing the mouse '''right button'''. When you release the mouse button, a contextual menu offers to create a function or a function type:
  
To open the working example in the COMPASTA distribution, follow the steps below.
+
:[[File:ClipCapIt-221116-133603.PNG]]
  
    $ source ~/.bashrc.taste
+
Choose "Function", and rename the box:
    $ cd ~/tool-inst/share/compasta-code/examples/models/battery_sensor
 
    $ taste
 
  
The COMPASTA workflow is composed of the following steps.
+
:[[File:ClipCapIt-221116-133927.PNG]]
  
== Modeling the System Architecture ==
+
Create a second function next to it.
  
The system architecture is modeled using TASTE Interface View graphical editor. A new implementation language called "slim" is provided to specify the behavior of the HW components. COMPASTA supports SDL to specify the behavior of the SW components, and slim for the HW.
+
Then keep the Ctrl key and the left mouse button clicked to draw a line between the two functions:
  
COMPASTA expects that the TASTE model contains a top-level block called "SystemBlock", containing a (flat) hierarchy of components (both HW and SW components).
+
:[[File:ClipCapIt-221116-134009.PNG]]
  
:[[File:ClipCapIt-221111-153210.PNG]]
+
When you release the mouse button, a connection will appear and a dialog will let you name this connection:
  
:[[File:ClipCapIt-221111-153236.PNG]]
 
  
 +
:[[File:ClipCapIt-221116-134200.PNG]]
  
HW-SW communication is realized via unprotected ports, whereas SW-SW communication may also use sporadic interfaces. SW components must have an input cyclic port. SW components are implemented in SDL, using OpenGEODE. HW components are implemented using the Slim language.  
+
You can select the "kind" of connection this is. It can be an asynchronous message ('''sporadic''') or a simple, immediate function call (e.g. '''unprotected''').
  
In COMPASTA, we need to model open systems (e.g., for contract-based analysis), i.e., systems with unconnected interfaces at the top-level. Since this is not supported in TASTE, COMPASTA requires "SystemBlock" to be connected to an additional component called "PROPS" which is used to connect the open interfaces from "SystemBlock".
+
Add a connection in the other direction by using Ctrl+Left Click from the function on the right and releasing the keys when hovering on the left function. If you name it "Hi", it will look like this:
  
== Modeling the Behavior of HW Components ==
+
:[[File:ClipCapIt-221116-134541.PNG]]
  
The behavior of a HW component is specified in slim.
+
Last, we will add a cyclic interface to the "caller" function. To do this, right click on the Caller function and choose the "Provided Interface" option from the menu entry:
The slim language is defined in COMPASS and adapted in COMPASTA. Documentation can be found in [https://www.compass-toolset.org/documentation/].
 
  
The fragment of the language supported in COMPASTA is documented in the syntax and semantics document distributed with the tool.
+
:[[File:ClipCapIt-221116-134816.PNG]]
  
First, we set the Slim language to a function block by right-clicking on the block and by selecting "Properties" from the contextual menu.
+
In the dialog, name it ("trigger", choose "Periodic" for the kind attribute, and leave the period to 1000 ms:
  
:[[File:ClipCapIt-221111-111123.PNG]]
+
:[[File:ClipCapIt-221116-134925.PNG]]
  
The "Properties" window appears. Slim can be set as implementation language in the tab "Implementations".
+
== Create data types ==
  
:[[File:ClipCapIt-221111-111419.PNG]]
+
TASTE software works with data, and relies on well defined data structures. They are captured with the ASN.1 language.
  
The behavior can be edited by selecting “Edit implementation” from the same contextual menu seen above. As a result, a syntax-highlighted SLIM file will be created and opened in Space Creator’s editor. An example specification is shown below.
+
On the Workspace area of the editor you will see a file with the ".asn" extension. The file name itself is the name of your project. Double click on this file to open the editor. The default file contains a lot of built-in documentation to help you with the syntax of the language.
  
:[[File:ClipCapIt-221111-111724.PNG]]
+
For this example we will create a type to store a simple counter with a range of values from 0 to 3:
  
If the file does not exist, a new file is created, containing a comment at the top with information about the function interfaces in the TASTE model along with a skeleton code.
+
:[[File:ClipCapIt-221116-135538.PNG]]
  
:[[File:ClipCapIt-221111-111850.PNG]]
+
After this is done, go back to the main diagram by selecting the file named "interfaceview.xml". Note that you may also split the window in the IDE to view both files at the same time.
  
== Modeling the Behavior of SW Components ==
+
== Select the implementation language of each function ==
  
The behavior of a SW component is specified in SDL using the OpenGEODE editor.
+
To create an implementation of the system, we have to select a language for each function (caller and callee). We will use C for the callee and SDL for the caller.
For SDL, see the [[Detailed SDL tutorial]].
+
To do this, double click on each function, and select the tab named "Implementations". Change the language accordingly (the default being SDL, there is no need to touch the caller function):
  
The behavior can be edited by selecting “Edit implementation” in the contextual menu.
+
:[[File:ClipCapIt-221116-135952.PNG]]
An example specification for the "FDIR_2" component is shown below.
 
  
[[File:opengeode2.png]]
 
  
 +
== Implement the functions ==
  
The following SDL constructs are not (yet) supported by the COMPASTA translator:
+
We start with the "callee" function. Right click on the function and select "Edit Implementation" from the contextual menu.
 +
After being prompted to save the model (do it), wait a few seconds to enter the C editor in the IDE:
  
* Array type
+
:[[File:ClipCapIt-221116-140250.PNG]]
* Nested structures
 
* Nested states
 
* Parallel states
 
* Exported procedures
 
  
== Modeling Faults, Properties, Contracts and Requirements ==
+
Edit the code at will. The IDE provides auto-completion and on-the-fly syntax and semantic checks:
  
To model faults, from Space Creator’s menu bar, select "Tools → COMPASTA Tools → Edit Faults".
+
:[[File:ClipCapIt-221116-140500.PNG]]
  
:[[File:ClipCapIt-221111-114529.PNG]]
+
When you are done, go back to the main diagram editor (double click on "interfaceview.xml" in the workspace on the left).
  
 +
Right-click on Caller and choose "Edit Implementation". This will open the SDL editor (OpenGEODE).
  
A syntax-highlighted slim file named fault.slim opens within Space Creator’s editor. This file contains fault injection specifications for all the HW components' blocks. An example is shown below.
+
:[[File:ClipCapIt-221116-140708.PNG]]
  
:[[File:ClipCapIt-221111-114700.PNG]]
+
If you are not familiar with SDL, a complete documentation is built-in the tool (on the right).
 +
Double click on the Caller block to enter the state machine editor.
  
If the file does not exist, a new file is created, containing a comment at the top with information about the function interfaces with a skeleton code.
+
You can create the state machine using the set of symbols on the left of the editor. In this example, when the periodic trigger is received, the "Hello" message will be sent (to the callee function), and then the "Hi" message will be expected in return. After a few cycles, we enter a state named "Enough" and stop repeating this polite exchange.
  
A similar workflow applies to the specification of contracts, properties and requirements.
+
:[[File:ClipCapIt-221116-142433.PNG]]
Example specifications are shown below.
 
  
 +
You may want to visualize this simple state machine with a "statechart" representation. Click on the corresponding tab on top of the editor:
  
Contracts are specified using the slim syntax defined in COMPASS.
+
:[[File:ClipCapIt-221116-141927.PNG]]
  
:[[File:ClipCapIt-221111-115442.PNG]]
+
You may now save the model and quit OpenGEODE, to get back to the main interface view.
  
 +
== Quick build and run ==
  
Properties are specified in slim, similarly to COMPASS. COMPASTA supports specification of generic properties, and specification via property patterns.
+
At this stage you can already build the system. Click on the "Play" button on the bottom left corner of the tool:
  
:[[File:ClipCapIt-221111-115559.PNG]]
+
:[[File:ClipCapIt-221116-142131.PNG]]
  
  
Requirements are specified with reference to existing properties.
+
After a few seconds of build, you will see the system run in a console:
  
:[[File:ClipCapIt-221111-115740.PNG]]
+
:[[File:ClipCapIt-221116-142547.PNG]]
  
== Verification and Validation ==
+
When you do Ctrl-C to stop the application you can visualize a log of the execution in a file that was generated and that appeared in the workspace:
  
In COMPASTA, fault specifications are automatically injected into the system model (called the ''nominal'' model). The resulting model is called ''extended model'', since it is extended taking into account the fault specifications. The user can carry out verification and validation analyses either on the nominal or the extended model (some analyses, e.g. RAMS analyses, are carried out on the extended model by default, since they have to take into account the faults). The model(s) along with the specifications of properties, contracts and requirements are input to the verification and validation engines.
+
:[[File:ClipCapIt-221116-142758.PNG]]
  
The verification GUI can be opened from TASTE’s menu bar: "Tools → COMPASTA Tools → Open Verification GUI".
+
== Create a deployment to run on target ==
  
:[[File:ClipCapIt-221111-145141.PNG]]
+
This quick build produced a Linux binary. But you may want to build on a different platform, for example a Leon processor with the RTEMS6 Qualified RTOS.
  
 +
To do this you need to model the deployment of your system. On the workspace, right-click on "Other files" and choose "Add new"
  
The GUI gives access to the following tabs/sub-tabs which offer the corresponding verification methods:
+
:[[File:ClipCapIt-221116-143200.PNG]]
  
* Requirements Analysis
+
In the dialog select "Deployment View file":
* Contract-Based Analysis
 
** Validation
 
** Contract Refinement
 
** Tightening
 
* Correctness
 
** Property Verification
 
** Contract Verification
 
* Safety
 
** Fault Tree Analysis
 
** Failure Modes and Effect Analysis (FMEA)
 
** Hierarchical Fault Tree Generation
 
* FDIR
 
** Fault Detection Analysis
 
** Fault Isolation Analysis
 
** Fault Recovery Analysis
 
** Diagnosability Analysis
 
  
For each method, the user can select the desired parameters in a dedicated toolbar which is located at the top of the tab content.
+
:[[File:ClipCapIt-221116-143234.PNG]]
In the same tab, the user can select the formal specifications to be verified (e.g., properties).  The specifications are located immediately below the toolbar. Once the specifications are selected, the user can click on the button "Run" located on the left-hand side of the toolbar.
 
As a result, the verification task is started.
 
  
Below we show two examples (Property Verification and Fault Tree Analysis).
 
  
=== Property Verification ===
+
Then on the next screen you may rename it, but keep the ".dv.xml" file extension:
  
The Correctness → Property Verification contains three main sections: toolbar, "Property List" and "Fault List".
+
:[[File:ClipCapIt-221116-143320.PNG]]
  
:[[File:ClipCapIt-221111-150135.PNG]]
+
This will open a new editor, from which you can drag and drop deployment boards. Select for example this one:
  
The first row of the toolbar contains two buttons: "Run PV" on the left, and "Help" on the right.  
+
:[[File:ClipCapIt-221116-143650.PNG]]
"Run PV" will start the verification process, while "Help" shows the following dialog window:
 
  
:[[File:ClipCapIt-221111-150334.PNG]]
+
When you right click on the board, you can bind the functions (caller and callee) to it.
  
The 2nd row of the toolbar contains some radio buttons, used to select the verification engine (in this case, "BMC" or "KLIVE"), and the parameters for the engine (in this case, the "BMC bound"). Below the toolbar, there are two sections: "Property List" (containing the list of properties that can be selected) and "Fault List" (showing the set of faults that can be injected in the model).
+
Save the project, and click again on the "Run" button. This time the binary will be created using the RTEMS Cross compiler for the GR740 board that you selected, and it will execute using a SPARC/Leon built-in emulator. The output should be the same as before:
  
To start verification, the user can perform the following steps:
+
:[[File:ClipCapIt-221116-143903.PNG]]
* Select one property from "Property List" by clicking on the corresponding radio button (TIP: Keeping the mouse over a property item in the list, a tooltip will appear, showing the definition of the corresponding property).
 
* (optional) Check the "Extend Model with Fault Injections" (When checked, it enables the "Fault List" section, which is an expandable tree-view list of the injected faults. By default, the first fault in the list is already expanded).
 
* Select the desired engine and parameters.
 
* Click on "Run PV".
 
  
As a result of the verification task, the GUI will either show a message in the status bar saying that the property has been found true (possibly up to a given bound) or it will open the trace viewer showing a counterexample trace. In our example, the trace viewer will be opened with the following trace.
 
  
:[[File:ClipCapIt-221111-151339.PNG]]
+
... except for the timings, as the Leon emulator does not reproduce the waiting periods correctly (the 1 second beween each trigger isn't right). If you download this binary on a real board however it should work as expected.
 
 
=== Fault Tree Analysis ===
 
 
 
As another example, we show how to run Fault Tree Analysis. It can be run from the "Safety Fault Tree Analysis" tab.
 
 
 
:[[File:ClipCapIt-221111-151648.PNG]]
 
 
 
The user can select the property (corresponding to the top-level event in the fault tree), the verification engine and the corresponding parameters. The result of the analysis is a fault tree, which is opened in the fault tree viewer, along with a probability formula (the formula corresponding to the probability of the top-level event, in python format), which can be displayed by clicking on the corresponding message at the bottom of the GUI window.
 
 
 
:[[File:ClipCapIt-221111-151958.PNG]]
 
 
 
The complete list of verification and validation analyses available in COMPASTA are listed in more detail in the following section.
 
 
 
== Modeling and Verification Iterations ==
 
 
 
If the results of formal verification are not satisfactory, it is possible to iterate over the modeling and verification phases. For instance, it is possible to introduce additional redundancy in the system, to prevent single points of failure.
 
 
 
:[[File:ClipCapIt-221111-153702.PNG]]
 
 
 
 
 
== TASTE Workflow ==
 
 
 
The remaining part of the workflow consists in the standard TASTE workflow, i.e. deployment of the system on the target HW, code generation, testing, etc. For this purpose, the following steps can be executed.
 
 
 
=== Compilation-Ready Model Transformation ===
 
 
 
The model must be transformed by removing the HW components, and placing them with corresponding "HW I/O Components". The latter represent the interface components between SW and HW and can be modeled as SW components in TASTE.
 
 
 
:[[File:ClipCapIt-221111-154132.PNG]]
 
 
 
=== Deployment and Code Generation ===
 
 
 
Using TASTE, it is possible to specify the deployment view and perform code generation.
 
 
 
:[[File:ClipCapIt-221111-154711.PNG]]
 
 
 
=== Testing and Simulation ===
 
 
 
Finally, the resulting system can be tested and simulated.
 
 
 
:[[File:ClipCapIt-221111-154403.PNG]]
 
 
 
= Analyses Reference Guide =
 
 
 
This section provides a reference guide to the formal analyses that are available in COMPASTA.
 
 
 
== Requirements Analysis ==
 
 
 
=== Consistency ===
 
 
 
Checks the consistency of a set of requirements
 
 
 
Inputs:
 
* A set of requirements
 
Parameters:
 
* Engine: MSAT or IC3
 
* SAT bound (default 10)
 
Output:
 
* A witness trace showing that the requirements are consistent, or a message saying that it was not possible to prove that they are consistent
 
 
 
:[[File:ClipCapIt-221114-103542.PNG]]
 
 
 
=== Possibility ===
 
 
 
Checks that a set of requirements is compatible with another requirement
 
 
 
Inputs:
 
* A set of requirements
 
* A requirement (possibility)
 
Parameters:
 
* Engine: MSAT or IC3
 
* SAT bound (default 10)
 
Output:
 
* A witness trace showing that the requirements are compatible, or a message saying that it was not possible to prove that they are compatible
 
 
 
:[[File:ClipCapIt-221114-103555.PNG]]
 
 
 
=== Assertion ===
 
 
 
Checks that a set of requirements implies another requirement
 
 
 
Inputs:
 
* A set of requirements
 
* A requirement (assertion)
 
Parameters:
 
* Engine: MSAT or IC3
 
* SAT bound (default 10)
 
Output:
 
* A counterexample trace showing that the assertion does not hold, or a message saying that it was not possible to prove that the assertion is implied
 
 
 
:[[File:ClipCapIt-221114-103528.PNG]]
 
 
 
 
 
== Contract-Based Analysis ==
 
 
 
=== Validation ===
 
 
 
==== Consistency ====
 
 
 
Inputs:
 
* A set of contracts
 
Parameters:
 
* Engine: BMC or KLIVE
 
* SAT bound (default 10)
 
* UnsatCores (if set, generates UNSAT core showing inconsistency)
 
* Whole Architecture (if set, checks consistency of contracts of the whole architecture)
 
* Component
 
* All Contracts of all Components (if set, the check applies to all components)
 
Output:
 
* A counterexample trace showing that the contracts are consistent, or a message saying that it was not possible to prove that they are consistent
 
 
 
:[[File:ClipCapIt-221114-103116.PNG]]
 
 
 
==== Possibility ====
 
 
 
Inputs:
 
* A set of contracts
 
* A contract (possibility)
 
Parameters:
 
* Engine: BMC or KLIVE
 
* SAT bound (default 10)
 
* UnsatCores (if set, generates UNSAT cores in case a counterexample is generated)
 
* Whole Architecture (if set, the check is run on the whole architecture)
 
* Component
 
Output:
 
* A counterexample trace showing that the contracts are compatible, or a message saying that it was not possible to prove that they are compatible
 
 
 
:[[File:ClipCapIt-221114-103302.PNG]]
 
 
 
==== Assertion ====
 
 
 
Inputs:
 
* A set of contracts
 
* A contract (assertion)
 
Parameters:
 
* Engine: BMC or KLIVE
 
* SAT bound (default 10)
 
* UnsatCores (if set, generates UNSAT cores in case the check succeeds)
 
* Whole Architecture (if set, the check is run on the whole architecture)
 
* Component
 
Output:
 
* A counterexample trace showing that the assertion does not hold, or a message saying that it was not possible to prove that the assertion is implied
 
 
 
:[[File:ClipCapIt-221114-103226.PNG]]
 
 
 
=== Contract Refinement ===
 
 
 
Inputs:
 
* A set of contract refinements
 
Parameters:
 
* Engine: BMC or KLIVE
 
* SAT bound (default 10)
 
* Component
 
* All Refinements of all Components (if set, the checks applies to all components)
 
Outputs:
 
* A message saying that the refinements hold, or a counterexample trace if they do not
 
 
 
:[[File:ClipCapIt-221114-103150.PNG]]
 
 
 
=== Tightening ===
 
 
 
Inputs:
 
* A set of contract refinements
 
Parameters:
 
* Top-Down (weakening the assumption of the parent contract and the guarantee of its subcontracts) or Bottom-Up (strengthening the guarantee of the parent contract and the assumption of its subcontracts approach
 
* Shared Subcontract (consider other contracts refinements which have subcontracts in common)
 
* Component
 
Outputs:
 
* List of tightened contracts
 
 
 
:[[File:ClipCapIt-221114-103208.PNG]]
 
 
 
 
 
== Correctness ==
 
 
 
=== Property Verification ===
 
 
 
:[[File:ClipCapIt-221114-103332.PNG]]
 
 
 
=== Contract Verification ===
 
 
 
:[[File:ClipCapIt-221114-103322.PNG]]
 
 
 
 
 
== Safety ==
 
 
 
=== Fault Tree Analysis ===
 
 
 
:[[File:ClipCapIt-221114-103610.PNG]]
 
 
 
=== Failure Modes and Effect Analysis (FMEA) ===
 
 
 
:[[File:ClipCapIt-221114-103619.PNG]]
 
 
 
=== Hierarchical Fault Tree Generation ===
 
 
 
:[[File:ClipCapIt-221114-103630.PNG]]
 
 
 
 
 
== FDIR ==
 
 
 
=== Fault Detection Analysis ===
 
 
 
:[[File:ClipCapIt-221114-103444.PNG]]
 
 
 
=== Fault Isolation Analysis ===
 
 
 
:[[File:ClipCapIt-221114-103454.PNG]]
 
 
 
=== Fault Recovery Analysis ===
 
 
 
:[[File:ClipCapIt-221114-103507.PNG]]
 
 
 
=== Diagnosability Analysis ===
 
 
 
:[[File:ClipCapIt-221114-103435.PNG]]
 

Revision as of 13:40, 16 November 2022

Introduction

This tutorial explains how to quickly build a system using TASTE.

Make sure you have either installed the TASTE Virtual machine : https://download.tuxfamily.org/taste/TASTE-VM-10-64bit.ova

...or that you made a manual installation following the instructions here: Manual installation on a native platform

If you use the VM, note that the username and password to login are taste / tastevm

Important

Always make sure you are using the latest version of the TASTE tools. From within the TASTE Virtual machine or your native installation, open a terminal and run the following commands:

  $ cd tool-src
  $ ./Update-TASTE.sh

When it is done, close the current window and open a new terminal.

Hello World

This tutorial explains how to create a basic system to get familiar with the tool.

Create a new project

Run the following command:

  $ taste

You will be prompted for a project name and a new folder with this name will be created. Always use the taste command to re-open an existing project.

The Space Creator editor will show up:

ClipCapIt-221116-133346.PNG

Build the system logical architecture

In the main window, draw a rectangle while pressing the mouse right button. When you release the mouse button, a contextual menu offers to create a function or a function type:

ClipCapIt-221116-133603.PNG

Choose "Function", and rename the box:

ClipCapIt-221116-133927.PNG

Create a second function next to it.

Then keep the Ctrl key and the left mouse button clicked to draw a line between the two functions:

ClipCapIt-221116-134009.PNG

When you release the mouse button, a connection will appear and a dialog will let you name this connection:


ClipCapIt-221116-134200.PNG

You can select the "kind" of connection this is. It can be an asynchronous message (sporadic) or a simple, immediate function call (e.g. unprotected).

Add a connection in the other direction by using Ctrl+Left Click from the function on the right and releasing the keys when hovering on the left function. If you name it "Hi", it will look like this:

ClipCapIt-221116-134541.PNG

Last, we will add a cyclic interface to the "caller" function. To do this, right click on the Caller function and choose the "Provided Interface" option from the menu entry:

ClipCapIt-221116-134816.PNG

In the dialog, name it ("trigger", choose "Periodic" for the kind attribute, and leave the period to 1000 ms:

ClipCapIt-221116-134925.PNG

Create data types

TASTE software works with data, and relies on well defined data structures. They are captured with the ASN.1 language.

On the Workspace area of the editor you will see a file with the ".asn" extension. The file name itself is the name of your project. Double click on this file to open the editor. The default file contains a lot of built-in documentation to help you with the syntax of the language.

For this example we will create a type to store a simple counter with a range of values from 0 to 3:

ClipCapIt-221116-135538.PNG

After this is done, go back to the main diagram by selecting the file named "interfaceview.xml". Note that you may also split the window in the IDE to view both files at the same time.

Select the implementation language of each function

To create an implementation of the system, we have to select a language for each function (caller and callee). We will use C for the callee and SDL for the caller. To do this, double click on each function, and select the tab named "Implementations". Change the language accordingly (the default being SDL, there is no need to touch the caller function):

ClipCapIt-221116-135952.PNG


Implement the functions

We start with the "callee" function. Right click on the function and select "Edit Implementation" from the contextual menu. After being prompted to save the model (do it), wait a few seconds to enter the C editor in the IDE:

ClipCapIt-221116-140250.PNG

Edit the code at will. The IDE provides auto-completion and on-the-fly syntax and semantic checks:

ClipCapIt-221116-140500.PNG

When you are done, go back to the main diagram editor (double click on "interfaceview.xml" in the workspace on the left).

Right-click on Caller and choose "Edit Implementation". This will open the SDL editor (OpenGEODE).

ClipCapIt-221116-140708.PNG

If you are not familiar with SDL, a complete documentation is built-in the tool (on the right). Double click on the Caller block to enter the state machine editor.

You can create the state machine using the set of symbols on the left of the editor. In this example, when the periodic trigger is received, the "Hello" message will be sent (to the callee function), and then the "Hi" message will be expected in return. After a few cycles, we enter a state named "Enough" and stop repeating this polite exchange.

ClipCapIt-221116-142433.PNG

You may want to visualize this simple state machine with a "statechart" representation. Click on the corresponding tab on top of the editor:

ClipCapIt-221116-141927.PNG

You may now save the model and quit OpenGEODE, to get back to the main interface view.

Quick build and run

At this stage you can already build the system. Click on the "Play" button on the bottom left corner of the tool:

ClipCapIt-221116-142131.PNG


After a few seconds of build, you will see the system run in a console:

ClipCapIt-221116-142547.PNG

When you do Ctrl-C to stop the application you can visualize a log of the execution in a file that was generated and that appeared in the workspace:

ClipCapIt-221116-142758.PNG

Create a deployment to run on target

This quick build produced a Linux binary. But you may want to build on a different platform, for example a Leon processor with the RTEMS6 Qualified RTOS.

To do this you need to model the deployment of your system. On the workspace, right-click on "Other files" and choose "Add new"

ClipCapIt-221116-143200.PNG

In the dialog select "Deployment View file":

ClipCapIt-221116-143234.PNG


Then on the next screen you may rename it, but keep the ".dv.xml" file extension:

ClipCapIt-221116-143320.PNG

This will open a new editor, from which you can drag and drop deployment boards. Select for example this one:

ClipCapIt-221116-143650.PNG

When you right click on the board, you can bind the functions (caller and callee) to it.

Save the project, and click again on the "Run" button. This time the binary will be created using the RTEMS Cross compiler for the GR740 board that you selected, and it will execute using a SPARC/Leon built-in emulator. The output should be the same as before:

ClipCapIt-221116-143903.PNG


... except for the timings, as the Leon emulator does not reproduce the waiting periods correctly (the 1 second beween each trigger isn't right). If you download this binary on a real board however it should work as expected.