Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]

   • As a basis for discussion, Jad has reviewed the scenarios and made the following observations: From the transformation scenarios reviewed, I can identify 3 kinds of transformations:
     1. Transformations where the integration need focuses on automating the steps required to perform the transformation - control integration. typical example is the scripting of code generation of FPGA using TCL.
        • This ought to be best handled using the Automation Server.
     2. model/data transformations where the integration need focuses on transforming data from 1 tool to another - data integration. Example, migrate from a UML model to a Simulink model.
        • Given that the focus is on data, should there be better direct support for this data integration in OSLC?
     3. A specific example of the above data-focused transformation is when migrating the same type of artefacts from 1 tool to another - equivalent tool.
        • In this case, would be more reasonable to use OSLC services instead of a transformation engine?

2. Discuss the AM transformation scenario AM transformation scenario

   • quick summary and questions - based on a reading of the scenario by Jad
     • 2 (new?) resources were defined in the scenario:
       • Entity Generator Resource - Entity Generator Resource is a resource that represents and manages a long running transformation of Entities to source code.
         • references a set of “oslc_am:EntityResource”s
       • Entity Resource - Entity Resource is a model element resource that represents an Entity. It has simple properties (name/type) and can be transformed into source code.
         • = an AM Resource? What is the relationship???
     • Scenario summary:
       • Loops through the oslc_am:EntityResource”s of a Entity Generator Resource
       • Produce a sourc file per EntityResource?
     • How do the defined resources relate to the Automation resources? (automation plan, automation request, automation result)
     • The looping through entities to produce source code - as defined in this scenario - does not seem to follow the Automation specification mechanism where a request is created to run the transformation, and producing a result.

Minutes

• An analysis of the transformation scenarios on the agenda were presented by Jad. (See agenda for the details)
• Unclear how mature the AM transformation is. We can only speculate on the meaning of the scenario.
  • Jad will followup with Steve to see the status of the AM scenario.
• Frederic will also try to invite someone from Mbat (AIT) that has implemented a transformation using the Automation Server & Asset Management, to present their work at the next meeting.

Attendees

Rainer & Frederic, & Jad

[[Category:Meetings]]

Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]

   • As a basis for discussion, Jad has reviewed the scenarios and made the following observations: From the transformation scenarios reviewed, I can identify 3 kinds of transformations:
     1. Transformations where the integration need focuses on automating the steps required to perform the transformation - control integration. typical example is the scripting of code generation of FPGA using TCL.
        • This ought to be best handled using the Automation Server.
     2. model/data transformations where the integration need focuses on transforming data from 1 tool to another - data integration. Example, migrate from a UML model to a Simulink model.
        • Given that the focus is on data, should there be better direct support for this data integration in OSLC?
     3. A specific example of the above data-focused transformation is when migrating the same type of artefacts from 1 tool to another - equivalent tool.
        • In this case, would be more reasonable to use OSLC services instead of a transformation engine?

2. Discuss the AM transformation scenario AM transformation scenario

   • quick summary and questions - based on a reading of the scenario by Jad
     • 2 (new?) resources were defined in the scenario:
       • Entity Generator Resource - Entity Generator Resource is a resource that represents and manages a long running transformation of Entities to source code.
         • references a set of “oslc_am:EntityResource”s
       • Entity Resource - Entity Resource is a model element resource that represents an Entity. It has simple properties (name/type) and can be transformed into source code.
         • = an AM Resource? What is the relationship???
     • Scenario summary:
       • Loops through the oslc_am:EntityResource”s of a Entity Generator Resource
       • Produce a sourc file per EntityResource?
     • How do the defined resources relate to the Automation resources? (automation plan, automation request, automation result)
     • The looping through entities to produce source code - as defined in this scenario - does not seem to follow the Automation specification mechanism where a request is created to run the transformation, and producing a result.

Minutes

Attendees

[[Category:Meetings]]

Starting 5th March 2014, meetings are to be held on the 1st Wednesday of every month.

Time: 10:00 PM Eastern, 9:00 AM Central, 8:00 AM Mountain, 7:00 AM Pacific, 4:00 PM Central Europe

• [[Conference call information]]
• [[Actions List]]

Next Meeting

05 March, 2014, at usual time.

Meetings agendas and minutes

[[Category:Meetings]]

Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]

   • As a basis for discussion, Jad has reviewed the scenarios and made the following observations: From the transformation scenarios reviewed, I can identify 3 kinds of transformations:
     1. Transformations where the integration need focuses on automating the steps required to perform the transformation - control integration. typical example is the scripting of code generation of FPGA using TCL.
        • This ought to be best handled using the Automation Server.
     2. model/data transformations where the integration need focuses on transforming data from 1 tool to another - data integration. Example, migrate from a UML model to a Simulink model.
        • Given that the focus is on data, should there be better direct support for this data integration in OSLC?
     3. A specific example of the above data-focused transformation is when migrating the same type of artefacts from 1 tool to another - equivalent tool.
        • In this case, would be more reasonable to use OSLC services instead of a transformation engine?

2. Discuss the AM transformation scenario AM transformation scenario

   • quick summary and questions - based on a reading of the scenario by Jad
     • 2 (new?) resources were defined in the scenario:
       • Entity Generator Resource - Entity Generator Resource is a resource that represents and manages a long running transformation of Entities to source code.
         • references a set of “oslc_am:EntityResource”s
       • Entity Resource - Entity Resource is a model element resource that represents an Entity. It has simple properties (name/type) and can be transformed into source code.
         • = an AM Resource? What is the relationship???
     • Scenario summary:
       • Loops through the oslc_am:EntityResource”s of a Entity Generator Resource
       • Produce a sourc file per EntityResource?
     • How do the defined resources relate to the Automation resources? (automation plan, automation request, automation result)
     • The looping through entities to produce source code - as defined in this scenario - does not seem to follow the Automation specification mechanism where a request is created to run the transformation, and producing a result.

Minutes

Meeting cancelled (only attendant was Jad)

Agenda moved until next meeting.

Attendees

Jad

[[Category:Meetings]]

Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]

   • As a basis for discussion, Jad has reviewed the scenarios and made the following observations: From the transformation scenarios reviewed, I can identify 3 kinds of transformations:
     1. Transformations where the integration need focuses on automating the steps required to perform the transformation - control integration. typical example is the scripting of code generation of FPGA using TCL.
        • This ought to be best handled using the Automation Server.
     2. model/data transformations where the integration need focuses on transforming data from 1 tool to another - data integration. Example, migrate from a UML model to a Simulink model.
        • Given that the focus is on data, should there be better direct support for this data integration in OSLC?
     3. A specific example of the above data-focused transformation is when migrating the same type of artefacts from 1 tool to another - equivalent tool.
        • In this case, would be more reasonable to use OSLC services instead of a transformation engine?

2. Discuss the AM transformation scenario AM transformation scenario

   • quick summary and questions - based on a reading of the scenario by Jad
     • 2 (new?) resources were defined in the scenario:
       • Entity Generator Resource - Entity Generator Resource is a resource that represents and manages a long running transformation of Entities to source code.
         • references a set of “oslc_am:EntityResource”s
       • Entity Resource - Entity Resource is a model element resource that represents an Entity. It has simple properties (name/type) and can be transformed into source code.
         • = an AM Resource? What is the relationship???
     • Scenario summary:
       • Loops through the oslc_am:EntityResource”s of a Entity Generator Resource
       • Produce a sourc file per EntityResource?
     • How do the defined resources relate to the Automation resources? (automation plan, automation request, automation result)
     • The looping through entities to produce source code - as defined in this scenario - does not seem to follow the Automation specification mechanism where a request is created to run the transformation, and producing a result.

Minutes

Attendees

[[Category:Meetings]]

Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]
2. Discuss the AM transformation scenario AM transformation scenario

Minutes

Attendees

[[Category:Meetings]]

Agenda

1. Review the Transformation scenarios from [[Engineering-Activities-Matrix]]
2. Discuss the AM transformation scenario http://open-services.net/wiki/architecture-management/Scenario:-Long-Running-MDD-Transformations/

Minutes

Attendees

[[Category:Meetings]]

Starting 5th March 2014, meetings are to be held on the 1st Wednesday of every month.

Time: 10:00 PM Eastern, 9:00 AM Central, 8:00 AM Mountain, 7:00 AM Pacific, 4:00 PM Central Europe

• [[Conference call information]]
• [[Actions List]]

Next Meeting

05 March, 2014, at usual time.

Meetings agendas and minutes

[[Category:Meetings]]

Agenda

1. Recap what we acheived in 2013
   • [[IntegrationScenario-SimulinkToCode]]
   • [[ES Development Setups]]
   • [[Engineering-Activities-Matrix]]
2. Present & discuss aims for 2014
   • [[Eliciting Integration Scenarios]]
   • track1
   1. clean-up, categorize & prioritize the list [[Engineering-Activities-Matrix]].
   2. Identify x top integration scenarios
   3. Detail each top integration scenario
   • Track2
   1. find more [[ES Development Setups]] to analysze

Minutes

1. clean-up, categorize & prioritize the list [[Engineering-Activities-Matrix]].

• We seem to have focused directly on the Transformation scenarios from [[Engineering-Activities-Matrix]].
• Steve shared http://open-services.net/wiki/architecture-management/Scenario:-Long-Running-MDD-Transformations/ that can be relevant if we are to work on Transformations.
• Rainer: What is the goal of the exercise to analyze transformations? Are we aiming for guidelines? How deep should we dig in each scenario?
• Action: Jad clean up the [[Engineering-Activities-Matrix]]

Attendees

Andreas Korff, Rainer, Frederic, Jad, Steve

[[Category:Meetings]]

Agenda

1. Recap what we acheived in 2013
   • [[IntegrationScenario-SimulinkToCode]]
   • [[ES Development Setups]]
   • [[Engineering-Activities-Matrix]]
2. Present & discuss aims for 2014
   • [[Eliciting Integration Scenarios]]
   • track1
   1. clean-up, categorize & prioritize the list [[Engineering-Activities-Matrix]].
   2. Identify x top integration scenarios
   3. Detail each top integration scenario
   • Track2
   1. find more [[ES Development Setups]] to analysze

Minutes

1. clean-up, categorize & prioritize the list [[Engineering-Activities-Matrix]].

- We seem to have focused directly on the Transformation scenarios from [[Engineering-Activities-Matrix]]. - Steve shared http://open-services.net/wiki/architecture-management/Scenario:-Long-Running-MDD-Transformations/ that can be relevant if we are to work on Transformations. - Rainer: What is the goal of the exercise to analyze transformations? Are we aiming for guidelines? How deep should we dig in each scenario? - Action: Jad clean up the [[Engineering-Activities-Matrix]] -

Attendees

Andreas Korff, Rainer, Frederic, Jad, Steve

[[Category:Meetings]]

Agenda

1. Recap what we acheived in 2013
   • [[IntegrationScenario-SimulinkToCode]]
   • [[ES Development Setups]]
   • [[Engineering-Activities-Matrix]]
2. Present & discuss aims for 2014
   • [[Eliciting Integration Scenarios]]
   • track1
   1. clean-up, categorize & prioritize the list [[Engineering-Activities-Matrix]].
   2. Identify x top integration scenarios
   3. Detail each top integration scenario
   • Track2
   1. find more [[ES Development Setups]] to analysze

Minutes

Attendees

[[Category:Meetings]]

Starting 5th March 2014, meetings are to be held on the 1st Wednesday of every month.

Time: 10:00 PM Eastern, 9:00 AM Central, 8:00 AM Mountain, 7:00 AM Pacific, 4:00 PM Central Europe

• [[Conference call information]]
• [[Actions List]]

Next Meeting

05 March, 2014, at usual time.

Meetings agendas and minutes

[[Category:Meetings]]

Agenda

1. Recap what we acheived in 2013
   • [[IntegrationScenario-SimulinkToCode]]
   • [[ES Development Setups]]
   • [[Engineering-Activities-Matrix]]
2. Present & discuss aims for 2014
   • [[Eliciting Integration Scenarios]]

Minutes

Attendees

[[Category:Meetings]]

Starting 5th March 2014, meetings are to be held on the 1st Wednesday of every month.

Time: 10:00 PM Eastern, 9:00 AM Central, 8:00 AM Mountain, 7:00 AM Pacific, 4:00 PM Central Europe

• [[Conference call information]]
• [[Actions List]]

Next Meeting

05 March, 2014, at usual time.

Meetings agendas and minutes

[[Category:Meetings]]

1. Join the teleconference:

1. Dial one of the following numbers:
   • Sweden +46 (0) 8 124 107 00
   • United States +1 424-203-8405
   • Canada +1 661-673-8605
   • Germany +49 (0) 30 25557610
   • United Kingdom +44 (0) 330 606 0510
   • Other https://www.freeconferencecall.com/free-international-conference-call/internationalphonenumbers.aspx
2. Enter the Participant Access Code:
   • 251682#

2. Join the webconference:

1. https://connect.sunet.se/oslc_es_ug/

If you have never attended an Adobe Connect meeting before:

Test your connection: https://connect.sunet.se/common/help/en/support/meeting_test.htm

Get a quick overview: http://www.adobe.com/products/adobeconnect.html

Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

[[Category:Meetings]]

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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.

Tool Chain Description

Tools, Stakeholders & Relationships

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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]]

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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.

Tool Chain Description

Tools, Stakeholders & Relationships

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]

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]

Tool Chain Description

Tools, Stakeholders & Relationships

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.

Process Description

[[Category:Working Documents]]

Meetings are held every fourth Thursday.

Time: 10:00 PM Eastern, 9:00 AM Central, 8:00 AM Mountain, 7:00 AM Pacific, 4:00 PM Central Europe

• [[Conference call information]]
• [[Actions List]]

Next Meeting

28 November, 2013, at usual time.

Meetings agendas and minutes

[[Category:Meetings]]