Application on the AIDA case study
To illustrate the full approach, we use a simplified model of an Unmanned Aerial Vehicle (UAV) based on the AIDA case study developed at the St-Exupery Research Institute. We use the following languages and tools:
- CAMEO Systems Modeler 19.0 SP4
- AADL Inspector from Ellidiss
- STOOD for AADL from Ellidiss
And Hardware architecture has been defined with inspiration from crazyflie aadl architectural model.
The AIDA Logical Architecture in SysML has been recalled at the beginning of this article. Here we put the focus on the UAV system and in particular the co-design of the electric/electronic and distributed software architecture.
The functional goal is to control the actual position of the UAV to fit the expected trajectory around the aircraft. Therefore, one must find the right control parameters so that the UAV can follow the expected trajectory within an expected maximum timing latency. Then, we want to verify the compliance of the selected hardware and software architecture to the timing requirements.
Recall of the AIDA Functional and Logical Architectures
The AIDA Functional Architecture is defined in SysML and presented below:
AIDA Functional Architecture
In this functional architecture, we detail the position and attitude control functions, as well as the compute thrust and generate thrust functions of the UAV.
The logical architecture is established with regards to emerging systems and sub-systems decomposition. In this example, we decompose the UAV into the following subsystems:
- Perception Subsystem
- Flight Management Subsystem
- Propulsion Subsystem
- Mission Management Subsystem
Then, we allocate the functions to the subsystems as follows:
AIDA Logical Architecture
Definition of Timing Requirements (end to end latency) in SysML
Next, we define the expected maximum latency of the measurement to thrust force control (performance of the control loop) in a specific functional chain defined in SysML, as presented below:
Functional Chain for Control Loop
This chain is extended with the duration constraint property defined with a range of valyues between min and max values. In our example: 0ms .. 10ms.
Initiate Logical Architecture in AADL
From this step, we perform the design of this system using the AADL language to support software design by taking into account hardware constraints and performing timing verification.
The first step is to translate the functional/logical architectures and functional chains defined in the SysML language toward a logical architecture using the AADL language. This step results in an AADL System Implementation using Abstract Components and end to end flows as illustrated below:
Resulting AADL Architecture from SysML Logical Architecture
In order to perform this translation, we convert our SysML Flow of Information of type “Trigger” into Event and Flow of Information of type “Data” in AADL Data exchanges. The functional chain is converted to the equivalent concept of AADL end to end flow with latency specification.
In this first structural approach, we propose the following mapping:
|System Engineering Concept
|Technical System Element
|Any other Port (Data, Material or Energy)
|Internal Dependency Relation
|End to End Functional Chain from operational scenario
||End to end flow
|Functional Chain Duration
||Time Duration Constraint
||Port Connection Feature
Define Hardware / Software components that fit with the logical architecture
Once we have created a logical architecture in AADL that is semantically equivalent to the SysML logical architecture, we can start exploring the physical architecture definition using AADL concepts.
We initiate the Physical Architecture from the Logical Architecture and start to design Physical Components (defined as System Components in AADL), one for each Subsystem:
- Mission Mgt Sub-System
- Perception Sub-System
- Flight Mgt Sub-System
- Propulsion Sub-System
Now we can explore the different physical technical solutions able to refine this logical architecture and we determine the appropriate physical components (hardware and software) which satisfy all the requirements (functional and non-functional such as timing requirements or expected temperature range, safety level of selected devices, constraints due to selected solutions, …).
This exploration space is wide and shall be done carefully with regards to the compatibility of the physical interfaces. In the following example, we select a design solution to minimise the cost and timing execution of the Flight Control Management from Targeted Attitude and Position input up to the generation of the Thrust Force. The engineering goal is to move the UAV with an expected maximum timing budget of 10 ms.
With this design, we propose a mapping from Sub-Systems to Physical Components as follows:
- Mission Mgt and Flight Mgt are implemented by the FlightMgtController System Electronic Control Unit (Hw and Sw components)
- Propulsion Sub-System is implemented by a PropulsionMgt System which is composed of 4 Electrical Motors and associated Propeller / Power adapter.
- Perception Sub-System is implemented by a Sensors_Module System which is composed of an integrated circuit which implements 3 sensors (accelerometer, gyroscope, magnetometer).
Note : In the Logical Architecture, the Perception Sub-System shall eprform the following internal functions:
According to the expected performance and available/selected technologies, some sensors may provide hardware support for FuseData. In the proposed solution we perform the selection based on costs, so we decide to perform FuseData using dedicated software and we allocate the FuseData function to the Flight Controller instead of Sensors module.
Define Hardware / Software architectures and bind them to the logical architecture
Then, we can design the software architecture while taking into account hardware constraints, and study the technical solutions to implement the logical components (selection of appropriate devices and processors, decompose functions into several processes, allocate processes to one or more processors, define interaction between the software and hardware elements, …). At this stage, hardware and software engineers shall analyse the suitability of the architecture regarding functional and non-functional requirements (such as timing requirements).
For this article, we propose a simplified electronic architecture using the following physical components :
- One MPU9250 device for Attitude/Position sensing usable with I2C interface. This device integrates the following sensors:
- Accelerometers : Digital-output triple-axis accelerometer with a programmable full-scale range of ±2g, ±4g, ±8g and
±16g and integrated 16-bit ADCs
- Gyroscope : Digital-output X-, Y-, and Z-Axis angular rate sensors (gyroscopes) with a user-programmable full-scale range of ±250, ±500, ±1000, and ±2000°/sec and integrated 16-bit ADCs
- Magnetometer: 3-axis silicon monolithic Hall-effect magnetic sensor with magnetic concentrator
- One 32 bits FlightController Processor for FlightControl functions execution: STM32F7x5
- One 32 bits Connectivity Processor for Connectivity features (BlueTooth Low Power mode): STM32WX5
- 4 electrical motors controlled by PWM outputs from the Main Processor
- 1 UART bus for communication between the Main Processor and Companion
With those choices, we suggest the following AIDA HW Architecture:
AIDA Hardware Architecture in STOOD for AADL
For software design, we suggest decomposing the software in 2 processes (connectivity and flight management). This is mainly due to the following elements:
- Different criticality level between the 2 software applications
- Different timing constraints between the 2 software applications
- Limited computing power to execute the both applications on one processor
- The main processor does not support all the required connectivity and interfaces
That is the reason why, in this proposal, we have performed the following decomposition:
- One Process dedicated to the Connectivity Stack (focus on communication interfaces with Uav Ctl Station and Pilot)
- One Process dedicated to FlightMgt related functions:
- Thread MissionModesMgt: implements RetrievePOI and MissionMgtModes functions
- Thread FlightControlLoop
- ControlUAVAttitude: implements Control UAV Attitude function
- ControlUAVPosition: implements Control UAV Position function
- ComputeThrust: implements Compute Thrust function
- Thread Driver I2C MPU9250: implements the interface with the Attitude Sensors Devices and functions of Perception Subsystem (AcquireAttitudePosition and FuseData)
- Thread CommunicationMgt: implements the communication interface with the Connectivity processor
- Thread Propeller Interface: implements the interface with the electrical motor command (PWM)
The proposed AIDA SW Architecture is presented below:
AIDA SW Breakdown Structure
AIDA SW Architecture in Ellidiss STOOD for AADL
Finally, we can perform the binding in a 3 steps process:
1. Allocate Software Processes to Hardware Processes
2. Perform correspondence/allocation between Abstract components (translated from SysML logical components) and Hw/Sw components.
3. Verify the consistency of the design by checking that all the logical components are bound to the Processes and the hardware components.
AIDA UAV Hw/Sw Architecture
Perform Timing Analysis thanks to AADL
Now, it is possible to use integrated AADL analysis (static analysis, scheduling analysis) thanks to some AADL compatible simulation tools such as AADL Inspector.
We can analyze the compliance to the expected end to end timing requirements :
And then, perform scheduling analysis with appropriate simulator to check the suitability of the technical solution parameters. Indeed, defining appropriate scheduling properties may be difficult to achieve because hardware elements have physical limits (sensors sampling time, …) and software timing properties (priorities, worst case execution time, data transmission delays, periods …) are not obvious to determine. Moreover, you may encounter feasibility issues to satisfy the allocated timing budget if the System Engineer does not have these constraints in mind.
In this example of scheduling simulation, we can observe that some deadlines are missed , which was not obvious to determine in the initial allocation phase.
The Systems Architect has to analyse the impacts of change requests from the proposed hardware/software solutions.
In this example, the systems engineer has performed an initial allocation of functions to logical components based on his initial knowledge. Then, the Hardware / Software Design team has performed analysis of existing components, devices and software components which exist as libraries. In our case, the analysis has shown that there is a mismatch between initially expected interfaces and provided interfaces by the selected sensor device (which implements Perception Subsystem). So, Hardware/Software design team performs a proposal to change initial allocation of FuseData function from Perception Subsystem to Flight Control Management subsystem.
So we update the Logical Architecture in SysML accordingly, as shown in the following figure:
Modified Logical Architecture after AADL analysis.
In addition, some timing budgets between subsystems can be adjusted regarding the feasibility of the proposed solutions when possible. Some changes in timing requirements or in interface definitions may have consequences on other engineering specialities or on other components. So, this impact analysis is not always straight forward (rather iterative).