As illustrated in Eliciting Integration Scenarios, we here collect a set of typical ES Development Setups.
So far, the list is collected through a couple of EU projects, with public documentations that directly or indirectly highlight tool integration needs for ES development.
For the resulting integration scenarios, see Engineering Activities Matrix.
Brake-By-Wire
source TIMMO-2-USE Brake-By-Wire Validator
{To be further detailed}
Small Wind Turbine
source: http://www.artemis-ifest.eu/sites/artemis-ifest.eu/files/A Tool Integration Industrial Case - A Small Wind Turbine.pdf
ABB demonstrator is a Small Wind Turbine which is small enough to handle within the scope of the project but complex enough to handle typical ABB technology with control automation. ABB do not produce wind turbines, but develop components used in wind turbines. The components used in this small wind turbine is not a ABB products, but is commercial available components used for the same or similar products except the rotor which is take from a RC helicopter. However, the tools and technology used for development is the same. [source: site]
Application Description
ES sub-domain: an application that is able to demonstrate future multicore CPU solutions and progress towards an holistic approach to towards late partitioning of SW/HW co‐design including FPGAs. [source: document, section 2.1]
Integration goals: linking between requirements and design that enable tracing requirements to design and to be able to replace one tool with a similar one. [source: document, section 2.1]
The prototype is suitable for closed loop control where a number of sensor elements and actuators are connected by various interfaces. The system performs relevant actions depending on the input signals, the internal system state, the configurable logic, and possibly on operator commands [source: document, section 2.3.1]
The demonstrator is a Small Wind Turbine which is able to generate power based on a rotating turbine powered by blades rotation in wind provided by a fan. The physical model of the demonstrator for SWT is shown in Figure 2‐3. It consists of a wind generator, anemometer (to measure the speed of wind), and the turbine itself. [source: document, section 2.3.1]
Figures 2.1 & 2.2 in source document highlight the set of tools involved, and their role.
sections 2.4.3.1 & 2.4.3.2 (specifically Table1 & Table2) in source document lists the tools used, and their specific usage in the design flow.
Process Description
Section 2.3.2 in source document details the process flow; highlighting its activities, the tools involved, artifacts being dealt with, etc. (Figure 2.5 is a good illustration.).
This content is the main source of integration needs to be further analyzed.
RF reciever
source: http://www.artemis-ifest.eu/sites/artemis-ifest.eu/files/A Tool Integration Industrial Case - Radio Frequency Receiver.pdf
The industrial case which will be used by Selex ES to trial the iFEST framework will be a streaming design implementing a digital radio frequency (RF) receiver. RF receivers areused by Selex ES in its products to sense at radio frequencies the electromagnetic environment that surrounds the platform on which the product is fitted. This platform isusually mobile, for example an aircraft, boat, unmanned aerial vehicle (UAV) or even a human being. [source: site]
Application Description
Overall Aim: to make extensive use of model driven techniques for analysis and code generation. [source: document, section 2.1]
a digital RF receiver. RF receivers are used by Selex ES in its products to sense at radio frequencies (RF) the electromagnetic environment that surrounds the platform on which the product is fitted. This platform is usually mobile, for example an aircraft, boat, unmanned aerial vehicle (UAV) or even a human being. [source: document, section 2.3.1]
The architecture is a data‐flow style pipeline, featuring high data rate systematic processing at the input side and lower data rate conditional processing towards the output. The industrial case is designed to be a simplified but representative example of the receiver products typically developed by Selex ES. [source: document, section 2.1]
Figure 2.1 in source document highlight the set of tools involved, their position in the development process, and relationships between the tools.
in addition, section 2.3.3 in source document lists the set of tools involved.
This content is the main source of integration needs to be further analyzed.
Process Description
section 2.3.2 in source document details the process flow; highlighting the tools being used, the traceability info between tools, and the activities done with each tool. (Figure 2.3 is a good illustration.).
This content is the main source of integration needs to be further analyzed.
ROVER
source: http://www.artemis-ifest.eu/sites/artemis-ifest.eu/files/A Tool Integration Industrial Case - ROVER.pdf
The industrial case will focus on a movable pan/tilt camera mounting a simple digital filter for the video acquisition subsystem in a real control system for our UAV/UGV systems, more in particular for the Rover family. The case is based on HW and SW co-design, where functionality relies on both areas, configuration and filtering, interfacing and characterization of devices to be used later in the real environment. [source: site]
Application Description
Integration goal: The integration of tools in a framework that may provide a complete traceability between the outputs and inputs of each tool no matter which phase (or phases) the tool covers. Besides, the utilisation of tools for HW‐SW co‐design, is another factor to be present, since it has been addressed by applying specific tools for the HW platform, such as Xilinx ISE. [source: document, section 2.1]
Integration goal: the framework must ensure a fluent communication among tools. The main aim is to provide a unique access point for the engineer when facing new developments or even modification on existing ones, and at the same time support the non‐pure‐engineering activities such us control management, reporting, etc. How we expect these tools to be orchestrated is presented in Figure 2-4, which shows the communication among tools. [source: document, section 2.1.1]
Integration goal: [source: document, section 2.2.1]
- to assess the project life-cycle of a subsystem of the rover control system in terms of traceability and HW/SW co-design. Therefore, we will develop the industrial pilot case going through the project phases, as defined in the iFEST approach: requirements engineering phase, design and implementation phases and verification and validation phase.
- the main stress will be put on the life‐cycle traceability. The iFEST outcomes are expected to help in the validation of the software elements based on the specified requirements, taking into account the HW‐SW aspects which should be applied directly in the HW‐SW co‐design models
Application/Domain: autonomous robots for inspection and exploration (ROVERS). The autonomous robot vehicles are composed of a significant amount of specific hardware components for their control. The autonomy is provided by a central CPU that processes the data coming from the sensors and sends commands to the rover’s actuators, which may be controlled by FPGAs. [source: document, section 2.2.1]
Application: Surface planetary exploration vehicles, known as “rovers” or autonomous ground vehicles (AGVs’). For the sake of simplicity in terms of autonomy, the rover system can be divided into the following major systems: [source: document, section 2.1.1]
- The perception system is composed of those hardware subsystems which deal with the acquisition of the required data for an internal representation of the environment, such as cameras, stereoscopic cameras, lasers, sonar… and those software subsystems that process the acquired data.
- The navigation system includes those components that deal with the path planning, the traversability analysis, artificial intelligent techniques, etc., in the core of the rover’s hardware components.
- The locomotion system focuses on the sensors and actuators that the rover invokes in order to facilitate the mobility of the vehicle. It also contains the critical embedded software that interfaces directly with actuators and sensors.
A global picture of the tools used in the tool chain and their relationship/flow is depicted in Figure 2-1 & Figure 2.3 & 2.4.
section 2.2.4. & its subsections describe the tools to be used at the different developement phases.
section 2.3.2 gives a confined list of tools actually used in this industrial case.
Process Description
section 2.2.2 describes some general process together with the set of tools to be used at each stage.
Figure 2-7 depicts the tool process flow when developing the industrial case.
Thales Radar Application
source: http://www.artemis-ifest.eu/sites/artemis-ifest.eu/files/A Tool Integration Industrial Case - Radar Application.pdf
The goal of the Thales Radar application is basically to detect and follow flying objects in a nominal sector of sky. At a given moment, the radar observes a narrow angular sector in a direction by emitting a particular sequence of signal called dwell, and analyses the echo from this signal in order to detect the presence of objects (targets) and compute their distance and their speed. [source: site]
Application Description
Application goal: The goal of the Thales Radar application is basically to detect and follow flying objects in a nominal sector of sky. At a given moment, the radar observes a narrow angular sector in a direction by emitting a particular sequence of signal called dwell, and analyses the echo from this signal in order to detect the presence of objects (targets) and compute their distance and their speed. The radar must perform simultaneously two missions:
- A search mission where the whole sector is scanned exhaustively with the goal to detect new targets,
- An active tracking mission where already detected targets are observed more frequently in order to enable tracking (showing their past trajectory and speed). [source: document, section 2.1]
Application goal: The purpose of the radar application is to introduce some degree of dynamism, with state machine based control interacting with parallelisable, loop-based, sequences of Front End Signal Processing functions. [source: document, section 2.3.1]
Integration goal: The goal of this additional test application is to help to assess the iFEST methodology and tools chain in different conditions, which are mainly:
- Heterogeneity of computational patterns as the application involves several styles of computation together, such as high-performance front‐end Signal Processing followed by parallelizable intensive processing, finite states machines, etc. (appealing heterogeneous HW targets: FPGA, DSP, CPU)
- Impact of time, as explained above. This makes processing times and latencies become critical issues that directly impact the performance of the system and must be considered consistently from the high level system definition stage down to implementation. [source: document, section 2.1]
Integration goal: addresse one major objective of iFEST in the D&I area, which is to define generic models that must encompass a sufficiently wide range of applications. Moreover, it should be manageable by current or emerging state-of-the-art high level synthesis tools. [source: document, section 2.3.1]
We are interested in the product life cycle management services: process orchestration and automation, tracing, tracking and changes management. [source: document, section 2.2.2]
Figure 2.2 illustrates the list of tools, their place in the development life-cycle, and their relationships.
section 2.2.2 details the tools used, and section 2.2.3 details the usage of each tool.
section 2.3.3 (and its subsections) presents the list of tools, their place in the development life-cycle, and their relationships.
Process Description
Figure 2.7 illustrates the Thales Process flow.
Category:Working Documents
