Design of embedded mixed-criticality CONTRol systems … · CONTREX/STM/R/D4.2.2 Public...

CONTREX/STM/R/D4.2.2 Public

Implementation of use-case execution platforms and run-time systems (final)

Public

FP7-ICT-2013- 10 (611146) CONTREX

Design of embedded mixed-criticality CONTRol

systems under consideration of EXtra-functional

properties

Project Duration 2013-10-01 – 2016-09-30 Type IP

WP no. Deliverable no. Lead participant

WP4 D4.2.2 STM

Implementation of use-case execution platforms and

run-time systems (final)

Prepared by Sara Bocchio (STM)

Issued by STM

Document Number/Rev. CONTREX/STM/R/D4.2.2/1.0

Classification CONTREX Public

Submission Date 2015-12-31

Due Date 2015-12-31

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

© Copyright 2016 OFFIS e.V., STMicroelectronics srl., GMV Aerospace and Defence

SA, Cobra Telematics SA, Eurotech SPA, Intecs SPA, iXtronics GmbH, EDALab srl, Docea

Power, Politecnico di Milano, Politecnico di Torino, Universidad de Cantabria, Kungliga

Tekniska Hoegskolan, European Electronic Chips & Systems design Initiative, ST-Polito

Societa’ consortile a r.l..

This document may be copied freely for use in the public domain. Sections of it may be

copied provided that acknowledgement is given of this original work. No responsibility is

assumed by CONTREX or its members for any application or design, nor for any infringements

of patents or rights of others which may result from the use of this document.



History of Changes

ED. REV. DATE PAGES REASON FOR CHANGES

SB 0.1 2015-12-20 59 Initial version

RVP 0.2 2016-02-12 61 GMV’s contribution to section 2.3

LC, GP 1.0 2016-02-18 62 Vodafone and Polimi contribution

PA 1.1 2016-02-28 64 Eurotech update

SB 2.0 2016-02-29 65 STM contribution and final version.



Contents

1 Introduction ........................................................................................................................ 4

2 Use Case 1: Unmanned Aerial Vehicle Demonstrators ..................................................... 5

2.1 Brief description of the demonstrator platform ........................................................... 5

2.2 Use Case 1a: Multi-Rotor System demonstrator ......................................................... 8

2.3 Use Case 1b: Remotely Piloted Aircraft I/O module Demonstrator Platform ......... 16

3 Automotive Telematics Demonstrator Platform .............................................................. 22

3.1 Brief description of the demonstrator platform ......................................................... 22

3.2 AT demonstrator platform models ............................................................................ 31

3.3 AT platform runtime management ............................................................................ 45

4 Telecom Demonstrator Platform ...................................................................................... 57

4.1 Brief description of the demonstrator platform ......................................................... 57

4.2 Telecom demonstrator platform models .................................................................... 62

5 References ........................................................................................................................ 64



1 Introduction

This report describes the demonstrators’ implementation platforms of the three use cases, it

deals with their definition, implementation, and supporting run-time system and it is an update

version of deliverable D4.2.1.

The proper execution platform for each industrial use case is developed at the appropriate

platform abstraction level. Platforms are built “from the bottom up”; that is, starting from the

concrete hardware components. Abstraction for the use-case platform is derived starting from

the actual hardware platform, so that a model of the runtime properties can be to be analysed

and optimised for the use-case platform.

The runtime mechanisms implemented by the platform are modelled, taking into account the

link between runtime mechanisms and critical extra-functional properties, enabling the runtime

control and optimization of those properties.

In the project, the demonstrators are a layered HW/SW structure composed of HW execution

platforms, operating system, run-time manager, node abstraction layer, and application. All the

platform pass through the definition and implementation and have also to provide software

support services for the applications. It is thus possible to envisage common development

pattern to the three user cases platforms encompassing the refinement to their final

implementation for the supporting their target applications.

All the platforms are defined by the industrial partners, in collaboration with the research

partners. Platforms’ definition is carried out by specifying the architecture of building

components and communication facilities. This approach leads to a straightforward

implementation on SoC or MPSoC, building up the platform from its components in a bottom

up fashion starting from the concrete hardware components.

The intermediate implementation can lead to a real platform on FPGA, as in the unmanned

aerial vehicle demonstrator, where Virtual Platform or native simulation are in place to deal

with non-functional properties. It can also be made of a system of components for sensing

(SecSec, iNemo), data processing, automotive gateway, cloud communication infrastructure

and remote services infrastructure, as in the automotive user case. Or, as in the

telecommunication use case, can be composed of two cards connected each other by a GE cable

supporting Power Over Ethernet. Originally implemented by Freescale MPC880

microprocessor and Lattice FPGA has to be re-implemented on Xilinx Zynq.

Execution platforms are then endowed with supporting run time system, it can be the GMV AIR

hypervisor and the Real Time Resource Manager in user case 1, a cloud of semantic services

as in use case 2, use case 3 is provided of Linux os (xenomai), network stack, SNMP agent and

WEB server.

Important contribution is the development or exploitation of virtual platforms to provide link

and handling of the extra-functional properties. The unmanned aerial use case resorts to a

virtual platform for the Xilinx ZYNQ 7000 family which is available from Cadence [2], the

automotive use case resorts to its point tools or web frameworks to model and analyse the full

system, the telecommunications use case exploits Open Virtual Platform environment and

SCNSL for network simulation.

The document is organized into chapters corresponding to each of the three use cases targeted

within the project.



2 Use Case 1: Unmanned Aerial Vehicle Demonstrators

Use Case 1 was split into two different demonstrators, corresponding to two independent

systems, driven by OFFIS and GMV respectively.

The first one (the Use Case 1a) consists of an overall UAV controller that executes several tasks

of heterogeneous criticality levels. It is based on a pre-existing multi-rotor system that is used

as an aerial platform which will be extended by a Multi-Processor System on Chip (MPSoC) to

implement the safety-, mission- and non-critical functions of an autonomously civilian UAV.

The second one (the Use case 1b) is an adaptation from the I/O module of the Flight Control

Computer (FCC) of a pre-existing Remotely Piloted Aircraft (RPA). It consists of a series of

tasks (handling the data from different sensor devices) with different criticality levels deployed

on a Multi-Processor System on Chip (MPSoC).

These two demonstrators are aimed at focusing on two different sub-flows within the overall

CONTREX design and development flow, as well as on different goals. While the first

demonstrator is focused on VP-based simulation, and concentrates mainly on power and

temperature features, the second one does it on a (higher level) native simulation and automatic

DSE, concentrating mainly on timing and power features. Moreover, while the first

demonstrator is focused on the dissemination of methodologies and tools (by means of the

demonstrable flying system), the second one focuses on the exploitation of them.

Both demonstrators use the same MPSoC execution platform, which has been then customized

for each one according to the specific demonstrator’s requirements and needs. Section 2.1

provides a general description about the common execution platform, while sections 2.2 and

2.3 explain how this platform has been customized, respectively, for Use Case 1a and Use Case

1b demonstrators.

2.1 Brief description of the demonstrator platform

This section provides a general description about the execution platform that has been chosen

for the Use Case 1 (including both Use Case 1a and Use Case 1b demonstrators). It consists on

a Xilinx ZYNQ 7020 MPSoC, which combines multicore processors and programmable logic

and thus served well CONTREX purposes.

Both demonstrators use the real platform, which furthermore is being simulated, for the

consideration of the extra-functional properties, using different technologies: virtualization and

native simulation.

Section 2.1.1 briefly describes the main characteristics of the Xilinx ZYNQ 7000 family, while

sections 2.1.2 and 2.1.3 show the models of the execution platform that have been set up for

system simulation.

2.1.1 Xilinx ZYNQ 7000 family

As previously said, the Xilinx ZYNQ 7000 MPSoC family [2] combines multicore processors

and programmable logic. The multicore processor is represented by a dual ARM Cortex -A9

MPCore at 866MHz and an Artix-7 FPGA with 85k logic cells. The development with this



MPSoC is fully supported by the Xilinx Vivado Toolchain. The structure of this MPSoC is

shown in Figure 2.1.

Figure 2.1 Overview

Overview of the structure of the Xilinx ZYNQ family is described in [2]

The ARM dual core is connected to the peripherals by the AMBA® Interconnect. On the left

side the available interfaces are shown which can be connected to the pinout of the MPSoC by

the Processor I/O Mux. The AMBA Interconnect represents also the interface to Multiport

DRAM Controller and the Flash Controller as well as the connection to the Programmable

Logic (FPGA) part of the MPSoC.

With this flexible and heterogeneous MPSoC it becomes possible to process the presented

safety and real-time critical flight algorithms together with the mission-critical payload tasks

on a single MPSoC. With the Artix-7 FPGA it is possible to define and build further interfaces,

processing elements (e.g. MicroBlaze Softcore) or also specialized hardware for the payload

processing tasks. While the development and production of an own board is very time and cost

intensive, it was decided to use an industry board which is available at Trenz Electronic GmbH

[3]. The TE0720-01-2IF board, shown in Figure 2.2, has a dimension of 50mm x 40mm and a

weight of 20g. It is connected to an individual breakout board via the assembled industry

connectors on the bottom of the board.



Figure 2.2 TE0720-01-2IF industry board of Trenz Electronic GmbH [3]

While the ZYNQ has by standard only two UART interfaces, extra UART interfaces (a different

number for each of the demonstrators) had to be implemented in the Programmable Logic part.

The communication rates between the components were chosen so that they met the

demonstrator’s requirements with their timing constraints.

2.1.2 Virtual Platform for ZYNQ 7000

A virtual platform for the Xilinx ZYNQ 7000 family is available from Cadence [2]. The so-

called ‘Cadence Virtual System Platform for the Xilinx Zynq-7000 All Programmable SoC’ is

a fast and extensible simulation platform based on SystemC TLM2 intended for software

development (Figure 2.3).

Figure 2.3 Cadence Virtual Platform for ZYNQ SoC



The heart of the virtual platform is an instruction set simulator (ISS) for the ARM Cortex A9

dual core provided by Imperas as part of OVP. The Imperas ARM ISS is an instruction accurate

processor model including debugger interface and performance monitor registers. It provides a

native TLM interface for the integration in SystemC TLM2 based virtual platforms. The ISS is

extended with models for memory, on-board standard peripherals, interconnects, and display.

Altogether, this builds a virtual platform that allows running software, e.g. booting a Linux OS.

Further features of the virtual platform are the extensibility and the ability to be connected to

real world interfaces. The second allows to forward virtual interfaces of the virtual platform to

real interfaces of the host PC. For instance, one can connect the Ethernet port or USB ports. As

a result, the Ethernet or USB devices are accessible from inside the virtual platform.

The other feature, extensibility, allows the integration of additional, user-defined components

in the virtual platform. They can be given either as SystemC TLM2 components or as HDL

(VHDL/Verilog/SystemVerilog) implementation that will be co-simulated via the Cadence

HDL simulator framework. To do so, Cadence provides configuration files that describe the

virtual platform’s components, its internal structure and communication links. With this feature,

it is possible to integrate components that are meant to be implemented in the ZYNQ SoC’s

FPGA fabric on one hand, or components that are used for simulation only such as observer

modules connected to a bus.

In conclusion, the virtual platform provided by Cadence matches the requirements for the

CONTREX use-cases. It allows running the demonstrator applications and the extensibility

enables us to integrate extra-functional property models.

2.1.3 UML/Marte model of the demonstrator platform

In order to allow performance analysis and simulation, the execution platform modelled using

the CONTREX design methodology (based on UML/MARTE) and supported by the analysis

and simulation tools an execution platform model that is used for native simulation (using UC’s

VIPPE tool) has been developed. Its model is not shown here since it is similar to the one

described in section 2.3.2.

2.2 Use Case 1a: Multi-Rotor System demonstrator

Like mentioned in deliverable D4.1.1, OFFIS uses the described processing platform on its

multi-rotor system demonstrator. The already flying real part of the demonstrator with the

ZYNQ platform is shown in Figure 2.4.

Figure 2.4 Flying multi-rotor system with its avionics based on the ZYNQ platform



The ZYNQ MPSoC concurrently processes the safety-critical flight algorithms as well as the

mission-critical on-board video processing. To do so the ZYNQ platform is configured and

extended by specific parts for the multi-rotor demonstrator. This configuration and the

extensions are shown in section 2.2.1. For analyzing extra-functional properties of the avionics

a virtual platform of the real system will be used. These platform models are presented in section

2.2.2. In section 2.2.3 the runtime management methods, which are used for the safety- and

mission-critical parts of the system, are introduced.

2.2.1 Multi-Rotor specific extensions of the demonstrator platform

The multi-rotor system requires a specific configuration and also specific extensions of the

ZYNQ MPSoC. While the safety-critical flight algorithms have not to be influenced by the

mission-critical video processing tasks and the ARM Cortex-A cores of the ZYNQ are not

suited to process real-time algorithms, two MicroBlaze soft cores are implemented in the

programmable logic. An overview of the in the programmable logic implemented architecture

is shown in Figure 2.5.

Figure 2.5 Used hardware architecture of the ZYNQ MPSoC

The first MicroBlaze is responsible for the data mining of all data from the sensors (MPU9150,

BMP085 and battery guards) and the remote control receiver. The interfaces for connecting the

external components are also implemented in the programmable logic. In that way only the data

mining MicroBlaze has exclusive access to the interfaces. The received data is stored in a dual-

ported RAM, where the data mining MicroBlaze is the only component with write access to the

resource. The second MicroBlaze is used for processing the flight algorithms (e.g. attitude and

altitude controller) and calculating the set points for the motor drivers. This soft core has only

readable access to the first dual ported RAM to get data like attitude angles and the altitude of

the data mining MicroBlaze. The flight control MicroBlaze places its data in the second dual-

ported RAM, where this MicroBlaze is the only element with writeable access to the resource.



All other processing elements connected to the AMBA interconnect have only readable access

to this RAM. In that way a safety on-way communication is realized. For transmitting the

calculated set points to the motor drivers another I2C interface is implemented in the

programmable logic, with exclusive access by the second MicroBlaze.

Next to this IP cores some general purpose in-/outputs (GPIOs) are mapped in the

programmable logic for simple debugging outputs in form of LEDs, a Buzzer or plain Pins.

These GPIOs are directly mapped to the responsible components.

The mission-critical video processing tasks are executed on the ARM dual core system. For

these tasks and processing elements the already existing interfaces are used, which are available

over the AMBA interconnect. The USB interface is used to connect the camera, for capturing

the video image, the gimbal, for aligning the camera, and the Wi-Fi dongle, for transmitting

data to the ground control station. The SDIO interface is used to load the system configuration,

bitstream for the programmable logic, binaries and operating systems for the processing

elements while the system is booting. At least an UART interface is used to transmit telemetry

data for the pilot to the remote control display.

2.2.2 Multi-Rotor demonstrator platform models

To analyze extra-functional properties of the demonstrator a virtual platform of the avionics

with all major parts should be designed. For this the before in section 2.1.2 mentioned ‘Cadence

Virtual System Platform for the Xilinx Zynq-7000 All Programmable SoC’ would be used. This

virtual platform has the needed extensibility for the elements of the programmable logic which

were described one section before. Regarding the extra-functional properties the virtual

platform should be connected to three different models to analyze the timing, the power

consumption and the temperature of the MPSoC. These models would be characterized on the

real avionics, to get the specific data of the used system.

2.2.3 Multi-Rotor platform runtime management

In Figure 2.6 the mapping of the tasks of different criticalities to the processing elements is

shown.

Figure 2.6 Mapping of tasks to processing elements of the architecture



Next to the mapping the figure also opens up the used runtime management methods. The

safety-critical tasks of the system are scheduled statically and are mapped to the MicroBlazes.

This is done while the data mining and the flight control algorithms are consisting of a

sequential data flow which has only rarely intersections for some exception handling. Else the

data flow processes continuous the same operations in every cycle. The mission-critical tasks

are executed and scheduled dynamically by a Linux operating system. This is done while the

video processing has no static data flow and features can be switched on and off at runtime of

the system. So far the system has no runtime management to handle requirements regarding the

extra-functional properties.

2.2.4 UAV platform runtime management

The Run-time Resource Manager (RTRM) will be in charge of assigning computing resources

to non-critical tasks, taking into account extra-functional requirements, i.e., timing, power and

thermal constraints mentioned in deliverable D1.2.1.

Since, the usage of the two ARM CPU cores, provided by the ZYNQ platform, are shared

between mission-critical and non-critical tasks, it is mandatory to bound the effects due to the

execution of non-critical tasks. For instance, we must avoid unacceptable increase of

temperature of the chip, and keep under control the energy budget consumed by this class of

tasks, so that the mission-critical tasks fully exploit the resources provided by the platform.

2.2.5 Run-time resource management actions

As introduced in deliverable D3.3.1, the RTRM framework allows to control the resource

allocation and usage, both at application and system level.

Since non-critical tasks are expected to be image processing applications, it is reasonable to

think about tunable algorithms. This means implement adaptive applications, capable of carry

out results with different levels of accuracy, according to the amount of the available computing

resources. For instance, if an application needs to perform at a specific frame-rate, and the

assigned resources do not allow to reach such goal, it can decide to decrease the accuracy of

the results. This behaviour has an impact also from the point of view of the resource utilization,

and thus on the power consumption and the temperature of the processor.

As depicted in Figure 2.7, the application is notified about the assigned resources (Application

Working Mode selected by the RTRM), through the Run-Time Library (RTLib). Being aware

of the amount of exploitable resources, the application can implement the behaviour explained

above, enabling a kind of cooperative resource management.



Independently from the cooperative behaviour of the applications, the RTRM exploits suitable

interfaces provided by the Linux OS, to monitor the status of the hardware and enforce resource

allocation.

The monitoring of the hardware relies on the availability of suitable sensors on the platform.

Commonly, we are able to observe:

The current clock frequency of the CPU;

The temperature of the CPU;

The status of charge of the battery.

However, some versions of the ZYNQ 7000 series platform are also equipped with controllers

for voltage and current monitoring, making possible the reading of the current power

consumption of the computing platform. The resource allocation enforcement instead, exploits

specific frameworks included in the Linux kernel, as cpufreq and Linux Control Groups.

deliverable 4.1.1, non-critical tasks are not subject to timing requirements. Therefore the

resource allocation policy to be implemented, must assign resources taking into account the

constraints on the battery lifetime and the temperature of the avionics, with the RTRM ready

to react to constraints violations. The actions that the RTRM can execute, to guarantee such

constraints are:

Perform frequency scaling on the CPU;

Re-define the CPU resource allocation;

Stop an application.

The former point, requires the setting of the cpufreq framework governor to “userspace”. This

allows the RTRM to set the CPU frequency, according to the requirements of the non-critical

tasks and the extra-functional constraints previously mentioned.

The second, consists of bounding the utilization of the CPU by the applications, by dynamically

changing the number of CPU cores and/or the CPU bandwidth time assigned. This is done

thanks to the interface provided by the Linux Control Groups framework. … shows an example

of this resource management action.

Figure 2.7 RTRM interactions with hardware platform

and (non-critical) managed application



Finally, since we are talking about non-critical tasks, the RTRM can evaluate to stop the

application (process killing), especially if some misbehaviour are detected, e.g., a very fast

increase of temperature.

2.2.6 Power and thermal management abstractions

To the sake of portability, the RTRM framework implements an internal abstraction on top of

the OS monitoring interfaces. This abstractions relies on the (C++) classes described below,

and their member functions.

PowerManager

Most of the member functions defined by the class are so called “setter” and “getter” functions,

and take as first parameter a “resource descriptor” object referencing a system hadware resource

(e.g. the CPU).

Member function Arguments Description

GetLoad() Resource Percentage of current resource

usage.

Figure 2.8 Example of the RTRM re-

assigning the CPU bandwith time

quota assigned to the application



GetTemperature() Resource Current temperature of the

hardware resource specified, in

Celsius degrees.

GetClockFrequency() Resource Current working frequency, in

KHz.

GetAvailableFrequencies() Resource çist of the available clock

frequencies that can be set, in

Khz.

SetClockFrequency() Resource Set a new clock frequency, in

KHz.

GetVoltage() Resource Current voltage value, in mV.

GetVoltageInfo() Resource Voltage range allowed to power

supply the hardware.

GetFanSpeed() Speed of the fan installed on the

platform for thermal control, if

available.

SetFanSpeed() Set the speed of the fan installed

for thermal control.

GetFanSpeedInfo() Speed supported by the fan

installed for thermal control, in

RPM.

GetFanSpeed() Current speed of the fan installed

for thermal control, in RPM.

ResetFanSpeed() Reset the speed of the fan to

default value.

GetPowerUsage() Resource Current power consumption of

the resource specified (or of the

system, if sensors are available.

GetPowerState() Resource

Current power state, defined as

an integer number. A power state

implicitly defines a

voltage/frequency configuration.

SetPowerState() Resource

Set a power state, defined as an

integer number. A power state

implicitly defines a

voltage/frequency configuration.

BatteryManager

This class implements the module for monitoring the status of the battery, returning run-time

data to other client modules. The module will provide information about the estimated lifetime

of the battery, allowing the resource allocation policy to take decisions accordingly.



Member function Arguments Description

IsDischarging() Battery ID Status of the battery, indicating

whether it is discharging.

GetChargeFull() Battery ID Full charge status capacity, in

mAh.

GetChargeMAh() Battery ID Charging level of the battery in

mAh.

GetChargePerc() Battery ID Charging level of the battery in

percentage.

GetDischargingRate() Battery ID Current discharging rate, i.e.,

current drained, in mA.

GetEstimatedLifetime() Battery ID Remaining lifetime, in seconds,

given the current charge level.

GetTargetLifetime() Battery ID The target lifetime constraint.

2.2.7 Development status

The RTRM mechanisms and interfaces, described in the previous paragraphs, have been already

implemented and tested on different platforms, running a Linux operating system, as

summarized in the following table.

Platform Processor architecture Class

Desktops/Laptops Intel x86 32 and 64 bits

Pandaboard ARM Cortex A9 dual-core 32 bits

Insight ARNDALE ARM Cortex A15 quad-core 32 bits

ODROID XU-3 ARM Cortex A15 quad-core + Cortex A7

quad-core (big.LITTLE HMP) 32 bits

The ODROID XU-3 for instance, is an example of platform compatible with the ZYNQ 7000,

featuring an ARM CPU, chosen also for the availability of on-board sensors providing voltage

and current monitoring. This has made possible the implementation of most of the monitoring

interfaces defined in the PowerManager class.

Intel x86 laptops have been also used to test an implementation of the BatteryManager class,

on top of the ACPI interface.

Further developments will include the porting and testing of the RTRM on the computing

platform chosen for the avionics, and the development of a specific resource management

policy.



2.3 Use Case 1b: Remotely Piloted Aircraft I/O module Demonstrator Platform

As said in section 2.1, GMV has reused a subset of the FCC (Flight Control Computer) software

developed for a medium sized Remotely Piloted Aircraft. This subset, which includes most of

the FCC’s I/O module components that were previously deployed onto the FCC’s I/O card (see

Figure 2.9), has been adapted (according to the needs and the objectives pursued in CONTREX)

into a mixed-criticality threaded model with to be deployed onto the Xilinx Z-7020 MPSoC

execution platform.

Figure 2.9 Flight Control Computer

The ZYNQ MPSoC concurrently processes the sensor data processing tasks encompassed by

the Use Case 1b’s application components, which are associated different criticalities. In order

to support the connections with all the sensor devices, the real ZYNQ platform has been

extended by synthetizing extra UART ports in the programmable logic (see Figure 2.10).

Figure 2.10 Customized ZYNQ platform connected to IO sensor devices



For the study of the relevant extra-functional properties, system performance analysis and

simulations will be carried out. In order to enable it, different models of the execution platform,

associated to the different analysis and simulation technologies used, have been developed.

Although Use Case 1b demonstrator is mainly focused on native (high-level) simulation, to be

performed using UC’s VIPPE tool, the Virtual Platform model of the execution platform

(briefly described in section 2.1.2) is being also used, in order to serve as a reference for the

evaluation (in terms of speed and accuracy) of the VIPPE tool high-level native simulation

technology.

2.3.1 RPA IO specific extensions of the demonstrator platform

In order to support the needs of the Use Case 1b demonstrator’s application and take advantage

of the DSE capabilities brought by CONTREX, a series of extensions (sketched in Figure 2.11)

have been done on the basic ZYNQ platform. The main ones have been the synthesis of extra

UART ports and a Xilinx MicroBlaze processor on the ZYNQ platform’s programmable logic.

Figure 2.11 HW architecture of the customized ZYNQ platform

The extra UARTs have been assigned to the ARM9 cortex core or the MicroBlaze processor

depending on the criticality associated to the corresponding sensor data. For the exchange of

data between ARM 9 and the MicroBlaze processors, a bidirectional high-speed FIFO

STREAM channel has been connected to the corresponding AMBA buses. The data exchange

between the two ARM cores is carried out by means of shared OCM (On Chip Memory). The

external DDR3 memory has been distributed between the two ARM 9 cores as illustrated in

Figure 2.12.

Core 0

AMBA Interconnect

UART

Radio Altimeter

UART

Absolute pressure

transducer

UART

Differential pressure

transducer

UART

Magnetometer

SDIO

Discrete I/O

ETHERNET

CONTROL & MONITORING

ARM 9 cortex

MICROBLAZE

AMBA Interconnect

UART

GPS

UART

IMU

SDIO

PPS

FIFO STREAM

FIFO STREAM

Core 1

SHA

RED

M

EMO

RY

LINUX FreeRtos

Bare-metal

Xilinx MicroblazeSoft processor

Xilinx ZYNQ FPGA

Programmable Logic (PL)Disk

Access XADC

Temperature

Voltage

SFTP

Webservices

HTML

SSH

USB

Special sensors and/or external

extorage

Timer

Processing System (PS)

DDR3 Memory

SD CARD



Figure 2.12 Memory distribution between ARM 9 cores

The MicroBlaze processor only uses the FPGA’s internal memory, being 128 KB assigned to

data and other 128 KB for instructions. The usage of the external DDR3 memory by the

MicroBlaze have been disabled in order to avoid “timing” interferences with the ARM

processor due to bus sharing.

As shown by Figure 2.11, the basic SW execution platform consists of a Linux OS running on

the ARM 9 Cortex’s Core 0 (CPU0) and a FreeRTOS real-time operating system running on

Core 1 (CPU1). Applications on the MicroBlaze soft-core will run bare-metal.

One of GMV’s main concerns in CONTREX is to improve the avionics development flow by

introducing an extra Design Space Exploration (DSE) stage. The main goal pursued by the DSE

to be applied to Use Case 1b is to select a system configuration (i.e., a specific HW/SW

mapping) that allows to fulfil the requirements and constraints on the extra-functional properties

specified for the system while minimizing the overall power consumption. Thus, different

HW/SW mappings entailing different configurations of the execution platform will be

evaluated.

For instance, Figure 2.13 shows two of the design alternatives being considered. These

alternatives reflect different mappings of application components to platform resources: in one

of them, the MicroBlaze soft-core is used for the Flight Control component (that encompasses

the safety-critical tasks) while in the other one it is not used at all.

0x00000000

0x02FFFFFF

0x03000000

0x03FFFFFF

Linux

FreeRTOS

725MB

256MB

External DDR3 Memory distribution

CPU0

CPU1



Figure 2.13 Two of the architectural alternatives being explored in Use Case 1b

It has to be noted that the Use Case 1b design space includes, apart from those above, additional

design alternatives with different implications on the execution platform. Out of those, some

will be actually implemented in the real platform while others will be only reflected by the

platform models used for system simulation (either VP-based or native).

2.3.2 RPA IO demonstrator platform models

In order to enable the high-level native performance analysis and simulation carried out by the

VIPPE tool, the execution platform needs to be modelled using the UML/MARTE-based

CONTREX design methodology supported by the analysis and simulation tools.

Figure 2.14 shows an example of the architectural description of the demonstrator’s platform

using the CONTREX UML/MARTE modelling language.

Figure 2.14 Use Case 1b demonstrator’s platform architecture

The platform’s model depicted in previous figure reflects the architectural details of the

platform as well as the interconnection architecture’s elements (buses, bridges traversed) that

can have a potential impact on performance. Technological implementation aspects (e.g.,

whether a UART device is a pre-existing device of the Zynq processing system or a

configurable block within a FPGA) have been omitted. Instead, these aspects can be captured



in the characterization of the IO devices. This information, which can be useful in the

performance assessment (and thus in DSE), is not captured at this state of the development;

however, the model is ready for an easy incorporation of it.

Figure 2.15 shows the definition of the HW resources that have been instantiated in Figure 2.14.

There, it can be observed, for instance, that different component declarations are used for the

UARTs integrated in the Zynq processing system (“ZynqPS_UART”) and for the UARTs

implemented on the FPGA (“AXI_UART_16550”).

Figure 2.15 HW resources used in Use Case 1b demonstrator’s platform

Besides previous UML/MARTE-based modelling, the ‘Cadence Virtual System Platform for

the Xilinx Zynq-7000 All Programmable SoC’ model mentioned in section 2.1.2 will be used

to evaluate the accuracy of the results produced by the high-level native simulation technology.

These VP model will be in turn connected to other three different models (characterized on the

real Zynq platform) that analyze the timing, the power consumption and the temperature of the

MPSoC.

2.3.3 RPA IO platform runtime management

As said in section 2.3.1, the basic SW execution platform consists of a Linux OS running on

the ARM 9 Cortex’s Core 0 (CPU0) and a FreeRTOS real-time operating system running on

Core 1 (CPU1). In the case of the tasks running on the Linux kernel, a simple FIFO scheduling

mechanism will be used (only non-critical tasks, such as the ones encompassed by the Logging

component, will be run on Linux). In the case of the tasks running on the FreeRTOS kernel, a

priority-based dynamic scheduling mechanism (according to the schedulability analysis results)

is employed. The tasks to be run on the MicroBlaze processor are statically scheduled and

implemented (as a cyclic executive) bare-metal.

The solution evaluated in CONTREX, based on the execution of the demonstrator’s application

onto the Zynq MPSoC presents three main issues related to the real-time and mixed-criticality

nature of the application and the general-purpose character of the platform.

The first one is the timing interference between tasks of different criticality due to the

indeterminism introduced by the cache memories and the external memory bus that are shared

by the two ARM cores. This may lead to a negative impact on the performance of higher

criticality level tasks (running on the FreeRTOS and CPU1) caused by less critical tasks (as the



ones running on Linux and CPU0). While processor’s caches can be disabled in order to avoid

access collisions, the issue with the external memory bus can only be solved by moving all

critical tasks to the MicroBlaze processor, leaving the whole ARM 9 processor for non-critical

tasks. In order to maintain within the design space being explored in CONTREX the possibility

of having different criticality level tasks running on the ARM 9 cores, empirical evidence about

the correct timing performance of the critical tasks (running on FreeRTOS) will be provided

via system simulations. Other more sophisticated techniques, such as the probabilistic timing

analysis being developed in FP7 PROXIMA project, could be used for guaranteeing this correct

timing performance. Although the assessment and application of these kind of techniques is out

of the scope of the CONTREX project, their applicability to the avionics use case in conjunction

with the rest of methods, techniques and tools developed in CONTREX represents a good

candidate for extending the research on mixed-criticality systems in future projects.

The second issue regarding the solution adopted in Use Case 1b is the potential mapping of

tasks with different criticality levels onto the FreeRTOS running on CPU1 (as illustrated by the

alternative 1 in Figure 2.13), which leads again to a timing interference scenario. In this case,

the required temporal and spatial segregation is ensured, respectively, by the real-time scheduler

of the FreeRTOS kernel and its Memory Protection Unit support, which can assign exclusive

memory spaces to the different tasks.

Finally, the third issue is the existing power and temperature interference due to the deployment

of a mixed-criticality application onto a single SoC. The impact of this kind of interference is

addressed by means of the extra-functional property monitoring and run-time management

mechanisms described in sections 2.2.4, 2.2.5 and 2.2.6, which adequate the execution of non-

critical tasks and the configuration of their assigned resources to the needs and requirements of

the higher criticality level tasks.

During system simulations, extra features are required in order to manage extra-functional

properties. Power and temperature models have to be attached to the simulator, which moreover

needs to include some kind of introspection mechanism that enables to gather the evolution of

extra-functional properties over time. These models will enable the search, during the DSE

phase, for the optimal HW/SW mappings and system configurations according to the

requirements of the mixed-criticality application and the behavior of the extra-functional

properties.

While the extension and configuration of the Zynq platform described in sections above as well

as the deployment and execution of the corresponding demonstrator’s application on it has been

already completed, some of the run-time management mechanisms mentioned here are still

under development and/or assessment. They will be further documented in the corresponding

final demonstrator prototypes deliverable (D4.3.2).



3 Automotive Telematics Demonstrator Platform

Several non-automotive companies provide private and/or fleet vehicle drivers with a support

service in case of accident. The architecture is based on three main components: a sensing unit

for acceleration measurements, a localization unit for GPS reading and a data processing and

communication for identification of accidents and communication of position data either to

public authorities (hospital, police) or private support providers. The Automotive Telematics

Demonstrator will extend the commercial solution provided by Cobra to a new generation that

will provide more functionalities at better performances/power trade-off, as already described

in D1.2.1.

A general overview of the CONTREX tools and workflow used in Automotive Telematics

Demonstrator is shown in Figure 3.1 where the part highlighted are the object of this paragraph.

Figure 3.1 Contrex flow for Automotive telematics usecase


The final system architecture is reported in Figure 3.2.



Figure 3.2 Final architecture of the complete Automotive Telematics application

As a functional point of view, the iNemo represents the Low Cost Sensing unit, SecSoC is the

high end sensing Node and the eurotech Gateway with the Kura platform is the main ECU that

will interface with the cloud. The corresponding block diagram is reported in Figure 3.3. The

communication between the sensing units will be realized by a serial proprietary protocol.

Figure 3.3 Block Diagram of the Automotive Telematics use case

SeCSoC



3.1.1 The low cost sensing unit: iNemo-M1

The low-cost sensing unit will be implemented on the iNEMO-M1 platform, provided by ST.

Figure 3.4 The iNEMO M1 System-on-Board

The iNEMO-M1 is the first 9-DOF motion sensing System-on-Board (SoB) of the iNEMO

module family. It integrates multiple MEMS sensors from ST and a computational core:

The LSM303DLHC e-compass module. The e-compass module LSM303DLHC is a

system-in-package featuring a 3D digital linear acceleration sensor and a 3D digital

magnetic sensor. The accelerometer has full scales of ±2g/±4g/±8g/±16g and the

magnetometer has full scales of ±1.3/±1.9/±2.5/±4.0/±4.7/±5.6/±8.1 gauss. All full

scales available are selectable by the user.

The L3GD20 digital gyroscope. The L3GD20 is a low-power digital gyroscope able

to sense the angular rate on the three axes. It has a full scale of ±250 / ±500 / ±2000 dps

and is capable of measuring rates with several bandwidths, selectable by the user.

The STM32F103REY6 ARM® Cortex™-M3 32-bit microcontroller.

This 9-DoF inertial system represents a fully integrated solution that can be used in a broad

variety of applications such as robotics, personal navigation, gaming and wearable sensors for

healthcare, sports and fitness. A complete set of communication interfaces and motion-sensing

capabilities in a small size form factor (13x13x2 mm) and the possibility to embed ST’s sensor

fusion software makes the iNEMO-M1 system-on-board a flexible solution for high-

performance, effortless orientation estimation and motion-tracking applications. The

STM32F103REY6 high-density performance line microcontroller is the computational core of

the iNEMO-M1 module. It operates as the system coordinator for the on-board sensors and the

several communication interfaces. Exploiting the features of the MCU, the iNEMO-M1 offers

a wide set of peripherals and functions such as 12-bit ADCs, DAC, general-purpose 16-bit

timers plus PWM timers, I2C, SPI, I2S, USART, USB and CAN, that enable different operative

conditions and several communication options.

3.1.2 The High end Sensing Unit: SeCSoC

The prototypical version of the high-end node is based on a system-on-chip specifically

intended for image processing captured by a low-power CMOS camera. The architecture of the

SeCSoC (shown in Figure 3.5) extends the typical structure of a high-end microcontroller with



specific modules for image processing, ultra-low power analog modules, and power island and

clock gating capabilities. The SoC is based on the multi-core R4MP processor

The board (in Figure 3.6) that will be provided has a size similar to a credit card, and it includes

two VGA sensors, optional sensors connectors, USB, SPI , UART, JTAG host connectivity,

digital stereo microphones and pressure and temperature sensors. The adoption of multi-core

technology also in some of the sensing units will allow for an improved management of extra-

functional aspects such as power consumption, execution time, quality of service, security and

reliability. The proprietary cores can be programmed through a development toolchain

(gcc+GNU binutils based) released by ST. Moreover peripheral library APIs are available.

Figure 3.5 System-on-Chip SeCSoC architecture



3.1.3 The main ECU: EUTH MiniGateway High

The EUTH MiniGateway is a compact size device designed to support M2M (Machine to

Machine) applications. As described in the D3.2.1 and D3.2.2 deliverables, the EUTH

MiniGateway has been adopted in the automotive use case (UC2) to connect the Vodafone main

ECU installed in the car and the cloud platform that will gather all the data obtained from the

vehicles. In this context, Eurotech designed and developed a first working prototype of the

EUTH MiniGateway that follows the initial specifications defined in the D3.2.1 and has been

adopted in the development of UC2 demonstrator (see the following figure).

Figure 3.7 First version of the EUTH Minigateway

Figure 3.6 SeCSoC board



After the first set of prototypes, EUTH started the design of a new version of the Minigateway,

called Minigateway v2: the objective is to solve the issues and bugs identified in the first version

and try to introduce new useful features. The second version of the EUTH Minigateway will be

included in the final UC2 demonstrator and will be the candidate to become a new product of

the ReliaGate family of Eurotech M2M/IoT industrial multiservice gateways.

The main advantages of the new design include:

low power: only 2W, with a powerful single core ARM CPU.

IoT Ready: it provides a wide range of connectivity features, like global cellular modem,

GPS, WiFI, BLE, Fast Ethernet and Fieldbus interfaces, including CAN bus ports,

optoisolated digital I/Os, protected USB and serial ports.

Industrial and automotive grade: the Minigateway as been conceived to support wide

operating temperature, wide range power supply with transient protection, and E- mark

certification.

Globally deployable: it provides certified radios, therefore it can be installed globally.

It also supports Eurotech’s ReliaCELL 10-20, the global cellular module with leading

carrier precertification.

Open platform: it natively supports Kura, the IoT Java/OSGi based-programming

environment that accelerates gateway application development and enables remote

management.

Customizable: the modular design allows personalization and full customization

options, ranging from branding (“skins” and color) to deep HW/SW configurations.

The Minigateway is based on the TI AM335X Cortex-A8 (Sitara) processor family, with

512MB of RAM, 4GB of eMMC and a user-accessible microSD slot. It is a low power gateway

suitable for intensive workload in industrial and automotive applications: it supports a 9 to 36V

power supply with transient protection and vehicle ignition sense, two protected 232/485 serial

ports, 2 CAN bus interfaces, 2 noise and surge protected USB ports, and 4 isolated digital

interfaces. The Minigateway block diagram is illustrated in Fehler! Verweisquelle konnte

nicht gefunden werden..

The commercial version will support Everyware Software Framework (ESF), a commercial,

enterprise-ready edition of Eclipse Kura, the open source Java/ OSGi middleware for IoT

gateways. ESF is distributed and supported by Eurotech and adds to Kura the following

features: advanced security, diagnostics, provisioning, remote access and full integration with

EverywareTM Cloud (EC), Eurotech’s IoT integration platform. The new device will run

natively the Yocto embedded Linux operating system version 1.6.



Figure 3.8 Minigateway block diagram.

The following table describes the technical specification of the Minigateway V2.

Specifications Description

Processor CPU TI AM335X, 800 MHz, 1 core

Memory RAM 512 MB, DDR3

Storage

Embedded 4 GB eMMC

Other MicroSD slot (user accessible)

I/O interfaces

Ethernet 1x Fast Ethernet port

USB 2x USB 2.0 host port 1x USB 2.0 client port

COM 2x RS232/485 (Surge protected, RS485 fail-safe resistors user

accessible) 1x TTL Serial console

Digital I/O 2x Insulated Digital Input 2x Insulated Digital Output

Radio interfaces Cellular Integrated 3G, global, with GPSMicro SIM card slot available

behind the Service panel



GPS Integrated in Cellular

Wi-Fi / BT 802.11b,g,n / 4.0 BLE

Antennas

(external) 1x SMA Cellular1x SMA GPS1x SMA Wi-Fi / Bluetooth

Other

RTC Yes (user accessible battery)

Ext. watchdog Yes

EEPROM on I2C 256 kb

Sensors Not present

LEDs 1x Power1x Cellular activity 4x User configurable

Buttons 1x Reset, 1x Programmable

SIM slot 1x microSIM (user accessible)

Power

Input Nominal: 24 V dc; Range: 9 - 36 V dc with transient protection,

vehicle ignition sense

Consumption 2W idle

Environment

Operating Temp -20°Cto+70°C

Storage Temp -40°Cto+85°C

Certifications

Regulatory CE, FCC, E-mark

Safety IEC/UL 60950-1

Environmental RoHS2; REACH

Radio FCC, PTCRB

Cellular FCC, PTCRB

Ingress IP40

MTBF >40000 h or 5 years

Mechanical

Enclosure Material: ABS - Color: aluminum

Dimensions 139(L)x95(W)x48(H);mm

Weight 160 g

Mounting Removable DIN mounting kit



The following figures illustrate the first set of prototypes of the new version of the EUTH

Minigateway.

Figure 3.9 Minigateway side view.

Figure 3.10 Minigateway rear panel view.



Figure 3.11 Minigateway top view.

3.2 AT demonstrator platform models

3.2.1 Energy/Timing models for the node sensors

3.2.1.1 The low cost sensing unit: iNemo-M1

Based on a first, coarse-grained set of power figures derived from the detailed documentation

of the sensor devices and of the microcontroller MCU provided by ST and ST-POLITO,

important architectural decisions have been made (see Section 5.3.4). POLIMI and ST-POLITO

have then defined the optimal granularity for the refined characterization. Such results will be

used in the non-functional node simulator developed by POLIMI.

iNEMO-M1 platform application model used for node simulation will consider several power

characterization profiles according to the application scenarios described in section Fehler!

Verweisquelle konnte nicht gefunden werden.. According to them, each component of

iNemo could be in its normal or low-power running mode or, alternatively, in its sleep mode,

where the power consumption can be considered very low.

The general diagram shown in Figure 3.12 can be considered as the typical state machine

representing the operating cycle of each sensor device (accelerometer, magnetometer and

gyroscope) belonging to iNemo system:



Figure 3.12 iNemo sensor device operating states for power characterization

For each state it shall be fed with the information summarized below:

Power-down & sleep

Average current consumption when the device is only power supplied, but it is in its lowest

power consumption state.

Idle (not sampling, not reading)

Average current consumption when a sensor device is neither involved in any data sensing or

conversion nor communicate the acquired data to a host device (the MCU in our case).

Sampling

Average current consumption and conversion time, or, equivalently energy per operation. This

state refers to a single operation of sampling and conversion of the three (or six) axes for each

inertial motion device included in iNemo-M1.

Reading

Average current consumption for reading out a single tern, or, equivalently, average current

consumption for reading the entire FIFO.

Concerning the microcontroller core, the simulation model defines different states by

combining the state of the peripherals (on, no clock, no power), the state of the core (normal

mode, stop mode, stand-by mode) and the operating frequency. A precise characterization of

all possible combinations of such states is not necessary for the level at which the simulation

will be performed and most of the power figures can be found in the data sheet.

In addition to the core and the devices, the iNEMO M1 System-on-Board integrates power

supplies, voltage regulators and few other analog components. To provide a reliable model for

simulation, the quiescent power consumption (current absorption) of these section will be

provided.

3.2.1.2 Power Supplies

Battery SOC (and possibly lifetime in the case the discharge exceeds the battery capacity) will

be tracked using a circuit-equivalent battery model that is able to calculate at any point in time

the residual available charge (battery State-Of-Charge or SOC) based on a power request. The

model is the one of the two options described in D3.1.1 (see Figure 3.13), and can be

characterized using the method described in that deliverable starting from a set of specifications

easily available in most datasheets.



Figure 3.13 Battery model used in the simulation

The figure shows the conceptual behaviour of the model, which can be described either in

SystemC/AMS or in Matlab/Simulink depending on the needs.

Since the voltage value(s) used in the device are likely to be different from the nominal battery

output voltage (around 4V for a Li-Ion cell) and also for voltage regulation issues, a DC-DC

converter is needed. A model of a converter can be cascaded to the battery model; this converter

model can again be one of two types: a circuit equivalent model (using the netlist specified on

the datasheet of the target devices to be used), or a functional model expressing the converter

efficiency, i.e, the ratio of input (battery) power and output (converter) power, in terms of the

relevant quantities (typically, the output (load) current and the difference between input and

output voltages).

In this case, based on our experience, it is more general to use such a functional model rather

than a circuit model.

The overall model used in the simulator and in particular its interface is depicted in Figure

3.14The basic signals to be traced are the V and I signals; these are supposed to be inputs to the

model, and are derived from a trace where at each time stamp a value of load current (requested

to the battery) and the relative voltage level is reported.

The model has two extra interfaces.

Signal SOC is a status signal and reports the SOC (a %) of the battery. It can be used

to generate a condition such as "battery exhausted" when it falls below some pre-defined value

that can be also different from 0%.

Signal Enable is a control signal that can be used to somehow "detach" the battery

from a load in some particular case. It will not be initially used in our simulations.

Figure 3.14 Battery and converter model interface



3.2.1.3 The High end Sensing Unit: SeCSoC

The chip is divided in 3 main power island:

The whole digital system (IPU, µProcessor subsystems and digital peripheral) will be

implemented as a single retentive power island.

All SRAMs block with retention

All analog blocks will have power down mechanism

The power islands above will be controlled by the Always on logic (that can be considered as

the fourth power island.

The DSP cores implement internally clock gating and it is possible to switch on or off individual

clock for each peripheral (full peripheral clock gating) and put in power down mode the

complete digital and analog devices by disabling their respective supply converter. A fast power

up mechanism could be considered by keeping a small RAM in the always on domain for

register retention.

Operating Modes

RUN This is the normal mode. Different clock frequency (from 32 KHz to 48 MHz) can be chosen

as system clock. Individual clock gating is possible for each peripheral. It is possible to power

down analog peripherals not used by the application.

ZZZ If ZZZ instruction is used, ReISC core clock will be gated until next interrupt.

SNOOZE In this mode the internal analog and digital power islands are shutoff. The system state must be

saved and restored from the always on SRAM buffer (where retention is not present).

The real time clock can wake up the system as well as any selected external event.

SLEEP This is a “hard” low power state. In this mode all analog and digital blocks are shut off, only an

external event can power up the system.

The SeCSoC platform model will be modeled using DoCea Power ACePlorer: in the flow of

the model that we’re developing is viewed.

A cycle approximate simulator provided by ST has enough detail to execute the actual

embedded software, but is still fast enough to run non-trivial applications. This model must be

augmented with non-functional aspects to show the developer the effect of running the

embedded software from the power point of view. The results of the simulations can hardly be

as precise as RTL or gate level simulation, but they are the only option for early system level



modelling, and an improvement compared to handwritten scenarios. The simulation provides

functional stimuli to Docea Power model for the power simulation.

Figure 3.15 ACEplorer and Cycle simulator

The ST simulator provides some power and performances activity, and recognize power states

of the systems.



Power states have been defined. Characterization of these 4 states are concluded and provide

as input for power model of the platform in Aceplorer.

3.2.1.4 Low-cost sensor node modelling

The low-cost sensor node, being the most constrained element in the entire processing flow,

will be modelled in detail to estimate the execution times and the power consumption in the

different operating conditions. The model is then fed to the NSS event-driven simulator and the

activity of the application hardware and software will be traced. Based on the simulation results,

a “configuration” for the run-time manager BBQLite will be derived and plugged into the

general BBQLite service to control the behavior of the critical application tasks.

According to the overall design flow shown in Figure 3.1 the core tool supporting the low-cost

sensor node modelling is the non-functional node simulator. A clearer view of the design flow

to be adopted for characterization and analysis in Figure 3-16, where the design portion of the

flow is shaded out.



Figure 3-16: Characterization and analysis flow

Not highlighted in the figure for the sake of simplicity is the overall application model that

needs to be fed to N2Sim. Such a model is constituted by entities of two classes and several

different types:

Hardware devices (states, timing, power consumption)

Hardware events

Software ISR (timing)

Software driver’s function (timing, device state changes)

Software jobs (timing)

Software tasks (duty-cycle)

Each entity is decorated with a set of properties and is allowed to “post events”, i.e. to unblock

the execution of some software routine or to trigger cascaded hardware events.



Figure 3-17: Application model for simulation (simplified view)

As anticipated, the model is split into four classes of entities: devices, drivers, tasks and generic

jobs, and each entity is described using simple C code, suitably extended to introduce the

concept of event scheduling. In addition to the behavior, entities are decorated with non-

functional attributes (not shown in the figure, for the sake of simplicity) such as execution times,

latencies, periods and power consumption. An excerpt of the generated C code showing the

implementation characterization and the characterization of an hardware event is reported

below. First, the declaration portion (*.h file) describes entity names, device names, and collects

characterization figures.



// Dev State V mA

DECLARE_VI( LIS, idle, 1.8, 1.00 )

DECLARE_VI( LIS, sampling, 1.8, 6.50 )

DECLARE_VI( LIS, irq, 1.8, 1.05 )

DECLARE_VI( LIS, reading, 1.8, 7.75 )

...

// Dev Event Duration Period Power (V/mA)

DECLARE_EVENT( LIS, lis_sample, 20, 800, V(LIS, sampling),

I(LIS, sampling) )

DECLARE_EVENT( LIS, lis_irq, 5, 0, V(LIS, irq ),

I(LIS, irq ) )

...

Figure 3-18: Modelling hardware events (declaration section)

The actual implementation of the event behavior is generated (*.cpp) file. For the two hardware

events shown above, the implementation is the following.



// Globals: FIFO & FLAGS

FIFO(hwfifo,25)

FIFO(swfifo,10)

...

// Initial event

START_EVENT(lis_sample,0)

...

// EVENT: lis_sample

ENTRY(lis_sample)

START(lis_sample) {

LOG(LIS,lis_sample,S)

hwfifo.push();

POST( lis_sample_duration, EVENT(lis_sample,End), 0 )

POST( lis_sample_period, EVENT(lis_sample,Start), lis_sample_duration

)

}

END(lis_sample) {

if( hwfifo.level() >= 5 ) {

POST( 0, EVENT(lis_irq,Start), lis_irq_duration )

}

}



// EVENT: lis_irq

ENTRY(lis_irq)

START(lis_irq) {

LOG(LIS,lis_irq,S);

POST( lis_irq_duration, EVENT(lis_irq,End), 0 )

}

END(lis_irq) {

POST( 0, EVENT(lis_isr,Start), 0 )

}

Figure 3-19: Modelling hardware events (implementation section)

Given the simplicity of the model specification formalism and the complexity of building a

usable and complete GUI for graphical entry, additional effort has been devoted to further

simplify the language for textual description and the readability of the generated code. When

completed, the model is fed to the code generator and the source file and header file are

generated, compiled into a dynamic library and can be loaded at runtime by the simulation

kernel. For performance reasons, it is also possible to statically link the application model with

the simulation core. In general, executing the simulator requires specifying:

The dynamic library implementing the application model

The simulation time

The log verbosity level (mostly for debugging)

Optional device and/or event logging filters

Optional output format string

The output trace file, or standard output

An example of execution trace is reported in the figure below. The new format, richer and

slightly different from the one describe in D4.1.1 is the consequence of minor refinements

implemented to simplify the integration with battery models. Note that the timing, voltage and

current figures are dummy, while the event names and relation are those corresponding to the

actual model.



# Ts Dev Td Event A V I

15200 us LIS 20 us lis_sample S 1.8 V 6.5 mA


16020 us LIS 5 us lis_irq S 1.8 V 1.05 mA

16025 us CPU 50 us lis_isr S 1.8 V 9 mA

16075 us CPU 0 us task_acquisition S 0 V 0 mA

16075 us LIS 120 us lis_read X 1.8 V 7.75 mA

16075 us CPU 120 us lis_read X 1.8 V 9 mA

16195 us CPU 15 us filter X 1.8 V 9 mA

16210 us CPU 0 us task_acquisition E 0 V 0 mA






20020 us LIS 5 us lis_irq S 1.8 V 1.05 mA

20025 us CPU 50 us lis_isr S 1.8 V 9 mA

20075 us CPU 0 us task_acquisition S 0 V 0 mA

20075 us LIS 120 us lis_read X 1.8 V 7.75 mA

20075 us CPU 120 us lis_read X 1.8 V 9 mA

20195 us CPU 15 us filter X 1.8 V 9 mA

20210 us CPU 0 us task_acquisition E 0 V 0 mA

20210 us CPU 0 us task_analysis S 0 V 0 mA

20210 us CPU 18 us crash X 1.8 V 9 mA

20228 us CPU 90 us lowenergy X 1.8 V 9 mA

20426 us CPU 1000 us dump_lowenergy X 1.8 V 9 mA




21426 us CPU 0 us task_dump E 0 V 0 mA

...

Figure 3-20: Example of simulation output

This trace can then be post-processed through a flexible filter utility with the goal of producing

“secondary” traces suited for specific purposes. An example of such a post processing, shown

in the trace and the figure below, consist in isolating software events (tasks, jobs and

drivers/ISR to plot the microprocessor duty-cycle and to calculate its value.

# Start time Duration

0.004025000 0.000050000

0.004075000 0.000000000

0.004075000 0.000120000

0.004195000 0.000015000

0.004210000 0.000000000

...

# Elapsed time Running time Duty cycle

0.771404000 0.002453000 0.318 %

Figure 3-21: Example of post-processed trace for duty-cycle calculation

Figure 3-22: Plot showing processor activity for duty-cycle calculation (part)

Similarly, post-processed output traces and corresponding plots can be obtained, for example,

for power consumption, cumulated energy consumption, bandwidth usage over the serial line

and so on. Two further examples of the results obtained with post processing are shown in

Figure 3-23 and Figure 3-24. The former figure shows the accelerometer’s interrupt requests



and the current consumption in the three possible states, namely idle, sensing and reading (while

sensing). Note that the current consumption values used to generate the figure are rough

estimates and will be replaced by actual data as soon as it becomes available. The latter figure,

on the other hand shows the tasks’ execution over time. Also in this case the durations of the

tasks are not derived from actual analysis.

Figure 3-23: Example of simulation post-processing – Accelerometer power consumption

Figure 3-24: Example of simulation post-processing – OS tasks and CPU power consumption



3.3 AT platform runtime management

3.3.1 Node-level extra-functional monitoring infrastructure

This section describes the lightweight framework used to monitor extra-functional properties

for applications in microcontroller-based nods and specifically for the iNemo-based low-cost

sensing unit used in the Automotive Use-Case.

The main purpose of the framework is to monitor system properties that depend on the run-time

context and activities of the application but that are not directly related to the application’s

functionality. The most common metrics are that have been considered for the first

implementation of the framework are:

Counters. This class of metric is devoted to monitor specific events occurring during

the application execution, such as accesses to device drivers, statistics on data-

dependent execution paths, errors, and so on. Such metrics are expressed in terms of

adimensional counters.

Timing. This class of metrics collects time-related properties of the application. The

main metrics in this class are execution time, both at task-level and at a finer-grained

level, if required, latencies, response times, throughput and so on.

Power/Energy. This class of metrics collects information related to the power

consumption. From a logical point of view, power consumption can be associated both

to physical devices (sensors, regulators, microcontroller, …) and to software functions.

In this latter case, the measure refers to the power consumption associated with the

microcontroller during the execution of the specific function.

Costs. This class of metric has been conceived to account for the costs associated to

data communication over the radio interface and is mostly related to the amount of data

being transmitted and the details of protocol-specific packet formats (size, overhead,…)

and handshake policies (retransmission).

From the implementation point of view, the framework is implemented as an external library

to be linked together with the application. The framework is meant to be general in terms of

extra-functional properties to be monitored and it’s closely tied with both the application and

the platform. For this reason, the framework has been designed to be used within UC2 as a

monitoring library.

The framework provides to an application the ability to monitor at runtime the desired metrics

with a function-level granularity. For each function the developer defines the relevant metrics

to observe for every device on the platform (in the general case the system is composed by

several processing elements beside the main processor, such as accelerometers and I/O devices).

Additionally, in order to gather the measures, the developer must instrument the region of code

that he wants to observe. Once these operations are performed, the framework automatically

senses the system and stores the observation values while the application is running and makes

them available to specific portions of the application responsible for using such measures to

implement local run-time management and/or to export them up to the cloud.

The framework is based on four main concepts:



Devices. A device is a physical component of the system that can be profiled in terms

of extra-functional properties.

Metrics. A metric is any extra-functional property relevant for the application, even if

it is not related to a physical quantity. For example time and energy are metrics, but also

the amount of data transferred by the system can be a metric.

Measures. A measure is defined by the metric, a numeric value and the related device.

The metrics and the devices must be defined in the configuration of the framework.

Events. The events are meant to express concepts such as “the frequency of the

microcontroller has changed to 200 MHz” or “the UART has consumed 20 mJ”.

The library has already been tested by integrating it into a dummy application composed a

limited number of tasks, each one executing one or two functions. The models, required for

metric estimation, are being completed and refined by the Use-Case partners and a first

prototypical integration has been experimented.

3.3.2 BBQLite

In the automotive use-case, and in particular on the low-cost sensor node, the monitoring

infrastructure, in conjunction with compile-time simulation-based characterizations, is used as

the source of information driving the behaviour of the system in varying operating conditions.

The management of the node’s hardware devices and software activities (functions and tasks)

will be under control of the BBQLite run-time manager.

A simplified view of the interaction of BBQLite with the configuration tools (design-time), the

application and the monitoring infrastructure (run-time) is shown in D4.1.1 and is reported here

in Figure 3.25 for the sake of readability.

Figure 3.25 Design-time and run-time interactions of BBQLite in UC-2



Run-time actions performed by BBQLite are based on three classes of information, namely:

Funtional Status. The application’s functional status, also referred to as operating-

mode. Given the requirement of the automotive application, a completely autonomous

management system solely based on non-functional properties will not satisfy

availability and functional needs. For this reason it is necessary to introduce the notion

of operating mode, that expresses the current functional status of the system, e.g. the

motion status of the vehicle or the status of the dashboard key. Associated to such states,

different sets of functions shall be mandatorily enabled/disabled, leaving to the non-

functional manager the role of managing power (and other) optimizations, possibly at

the cost of a degradation of the function being performed.

Extra-functional status. This information consist in the collection of metrics exposed

by the non-functional monitoring infrastructure. A separate configuration is required to

generate the necessary code and hooks enabling non-functional metrics estimation,

collection and access.

Design-time configuration. The configuration depends on the results of application

and node event-driven simulation, combined with user-defined policies explicitly

specified by the application’s developer. All this information is fed to the BBQLiteConf

configuration tool to generate the application-specific portions of the BBQLite run-time

manager. Note that in a more general scenario characterized by less stringent

memory/performance constraints, the configuration generated by BBQConfLite takes

the form of a (serialized) data structure parsed by the BBQLite engine at runtime and

does not require code generation and re-linking of the manager engine.

Figure 3.26 shows the relation among the different components of the run-time infrastructure

and the nature of the information being exchanged.



Figure 3.26 Integration of BBQLite with the extrafunctional monitoring infrastructure

As the figure shows, the BBQLite engine is not being executed at the level of task, but rather

as a sort of service that tasks can rely upon. This implementation can be improved by splitting

the BBQLite engine into two portions:

A core part running as a service and implementing the interactions between lower level

information and actions and the higher level tasks.

A task-level part belonging to the application level that can be executed periodically,

upon request or a combination of these two cases from all other tasks. The interaction

between functional tasks and the task-level BBQLite portion will be implemented with

standard IPC mechanisms.

In addition to this extension, the current implementation has been performed in order to

facilitate integration with the ARM RL-RTX microkernel. Integration, nevertheless, requires

operating-system and BSP-specific calls to be combined with the infrastructure. This has been

achieved by means of a call-back mechanism. As discussed above, two different approaches

and corresponding implementations are needed to efficiently manage the nod’s power

consumption:

3.3.2.1 Short-term management.

This portion of the BBQLite core is responsible for the short-time management of the power

consumption of the device. It operates with a typical time period comparable to the system tick,

that is, in the current implementation, 10ms. Its main purpose is to bring the system into a low-

power mode as soon as the idle task of the operating system is scheduled, that is, when no tasks

are requesting the CPU and no peripheral is raising interrupts. The low power mode is entered

as soon as the operating system is idle and no transactions are being executed. It is worth noting

that a “logical” transaction is often composed of several “physical” transaction. Physical

transaction cannot be interrupted as they are executed by ISRs, but logical transactions can be

interrupted and thus interleaved with bursts of idle task executions that would bring the system

in low-power, potentially (and in the specific case, actually) leading to wrong or unpredictable

behaviour. Figure 3.27 shows the execution of a logical transaction and its sub-structure, along

with correct power-state changes.

Figure 3.27 Logical/Physical transaction and short-term power management

To manage this situation, the concepts of “transaction start” and “transaction end” have been

introduced and rendered by means of suitable APIs. In addition to the CPU-related power

management, low-level functions are also needed to manage individual peripherals, such as



UART, SPI, I2C buses. As a result, the BBQLite programming interface requires to register

several callback by means of the following macros:

BBQL_REGISTER_INIT(fptr).

Registers the power management initialization function.

BBQL_REGISTER_ENABLE(fptr)

Registers a callback enabling the power management runtime support.

BBQL_REGISTER_DISABLE(fptr)

Registers a callback disabling the power management runtime support.

BBQL_REGISTER_MANAGE(fptr)

Registers the main power management function implementing the policies defined by the

configuration generated by BBQLiteConf.

BBQL_REGISTER_TRANSACTION_START(fptr)

Registers a callback defining the beginning of a logical transaction.

BBQL_REGISTER_TRANSACTION_END(fptr)

Registers a callback defining the end of a logical transaction.

BBQL_REGISTER_PERIPHERAL_ENABLE(id,fptr)

Registers a callback enabling the peripheral identified by the specific id.

BBQL_REGISTER_PERIPHERAL_DISABLE(id,fptr)

Registers a callback disabling the peripheral identified by the specific id.

Where fptr is a function pointer of type fptr_t to the callback function defined as:

typedef void (*fptr_t)(void)

and id is a global numeric identifier of specific peripherals. Such callbacks have been

implemented by the following functions, collected in an isolated module called PMU:



void PMU_Init ( void );

void PMU_Enable ( void );

void PMU_Disable ( void );

void PMU_SetLowPowerMode ( void );

void PMU_SetNormalMode ( void );

void PMU_TransactionEnd ( void );

void PMU_TransactionBegin( void );

In addition, the driver of each peripheral, has been enriched by two functions:

void <peripheral>_Enable (void);

void <peripheral>_Disable(void);

In the current implementation, the considered peripherals and devices are:

UART. The physical serial interface

SPI. The physical SPI bus

I2C. The physical I2C bus

LSM303. Accelerometer and magnetometer device

L3GD20. Gyroscope device.

3.3.2.2 Long-term management

Long-term management is based on the BBQL APIs defined in the Deliverable D3.3.1. The

description of the detailed implementation of such functions is beyond the scope of this

document and is thus omitted here.

More interesting is to describe how they hve been used, in conjunction with the extra-functional

properties monitoring infrastructure to actually perform monitoring and management of the

system.

As a first example, consider the following code, which is an excerpt of the actual

implementation of the monitoring task used for testing and measuring the application extra-

functional metrics.



__task void TASK_RTRM( void )

{

EFP_Metric_t eLSM, eUART, eBATT, eCPU;

// Initializes the monitoring framework. The code of this function

// is generated at compile time based on the XML specification file

EFP_FRAMEWORK_INIT();

// Starts the profiler. It will be subject to updates until the

// explicit call to the EFP_PROFILER_END() function

EFP_PROFILER_BEGIN(Profiler);

// The system is let to run for 100 ticks, i.e. one second

os_itv_set(100);

while( 1 ) {

// Waits for the interval to expire

os_itv_wait();

// Stops the profiler

EFP_PROFILER_END(Profiler);

// Collects metrics

EFP_PROFILER_GET_AVERAGE(Profiler, &eLSM, &eUART, &eBATT, &eCPU);



// Prepares a debug packet (omitted) and sends it

pkt.Length = sizeof( Ans_DebugRTRM_t );

...

PROTOCOL_Send( &pkt );

// Restarts the profiler

EFP_PROFILER_BEGIN(Profiler);

}

}

The main task of the Vodafone Automotive application is TASK_Analysis(), which performs

all the necessary computation on the data provided by the TASK_Acquisition(). As soon as the

acquition tasks has “enough” data to proceed with processing, it sends an event to the analysis

task which performs computation. The original structure of the analysis task has first been

enriched with the profiler calls to account for the energy spent for computation, leading to the

following (slightly simplified) implementation.



__task void TASK_Analysis(void)

{

DynamicData_t DynamicData;

AnalyzedData_t AnalyzedData;

while( 1 ) {

// Waits for data to be ready

os_evt_wait_and( EVENT_DATA_READY, WAIT_FOREVER );

// When unlocked, the tasks starts consuming CPU and thus the

// corresponding monitor shall be notified

EFP_MODEL_UPDATE(CPU,RUN);

// Processes data in the queue

while ( Q12_IsEmpty() == 0 ) {

JOB_Preprocessing ( &DynamicData );

JOB_Crash ( &DynamicData, &AnalyzedData );

JOB_Dynamics ( &DynamicData, &AnalyzedData );

JOB_Selfcalibration( &DynamicData, &AnalyzedData );

JOB_Shock ( &DynamicData, &AnalyzedData );

JOB_LowEnergy ( &DynamicData, &AnalyzedData );

JOB_DriverDNA ( &DynamicData, &AnalyzedData );

JOB_Debug ( &DynamicData, &AnalyzedData );

}



// The task finished its burst of computation and the model is notified

EFP_MODEL_UPDATE(MICRO,SLEEP);

}

}

To include the extra-functional management capabilities of BBQLite, it is sufficient to modify

the code above as described in the following. In particular, the following modifications are

needed:

1. Definition of the “flags” controlling individual jobs. This is done in the XML

configuration file and results, after code generation, in a set of symbols named after the

jobs, i.e. FLAG_Crash, FLAG_Dynamics, and so on.

2. Invocation of the main BBQLite management function. This might be done in the

analysis task, resulting in very frequent invocations, much more frequent than

necessary, considering that short-term power management is implemented in the idle

task and we are now dealing with long-term management. For this reason, the main

management function is better invoked in the dedicated TASK_RTRM() described

above, namely at the end of the loop, just before restarting the profiler.

3. Introduction of the code for management of the jobs. This is done checking the value

the flag associated to a job and executing the job only when the flags is true, that is:

if( BBQL_GetFlag(FLAG_<name>) == BBQL_TRUE ) {

JOB_<name>(<args>);

}

The macro:

BBQL_JOB_EXECUTE( FLAG_<name>, JOB_<name> )

Is provided to improve readability. The core loop of the TASK_Analysis() becomes thus:



// Processes data in the queue subject to BBQL management

while ( Q12_IsEmpty() == 0 ) {

// Preprocessing is always needed

JOB_Preprocessing( &DynamicData );

// Managed jobs

BBQL_JOB_EXECUTE( FLAG_Crash, JOB_Crash );

BBQL_JOB_EXECUTE( FLAG_Selfcalibration, JOB_Dynamics );

BBQL_JOB_EXECUTE( FLAG_Selfcalibration, JOB_Selfcalibration );

BBQL_JOB_EXECUTE( FLAG_Shock, JOB_Shock );

BBQL_JOB_EXECUTE( FLAG_LowEnergy, JOB_LowEnergy );

BBQL_JOB_EXECUTE( FLAG_DriverDNA, JOB_DriverDNA );

// Macro-enabled debugging job

JOB_Debug( &DynamicData, &AnalyzedData );

}

The current implementation is complete and provides all the required functionality expressed

in the specifications. It is interesting to note that significant effort has been devoted to simplify

the integration of the two EFPM and BBQL modules into generic user code, hiding all the

complexity of configuration, which is performed at high-level and at design time.



4 Telecom Demonstrator Platform


4.1.1 The current platform

The Ethernet over Radio System mainly consists of an OutDoor Unit (Figure 4.1), the ODU-

IP-LC (also abbreviated as ODU or ODU-IP). The ODU Unit encapsulates Ethernet packets in

a GFP frame, modulates, and sends them on the radio channel. Management packets are

redirected to a Controller Unit.

Figure 4.1 The current implementation of the OutDoor Unit (ODU)

The ODU implements all functionalities required by the system, in particular:

Signal base band processing

Modem stage

RF interface

User Ethernet interface

The ODU Card houses a Freescale communication processor based on the PowerPC core

(MPC880) with abundant RAM (64MB) and FLASH (32MB), one Ethernet interface (PoE)

and I2C/SPI bus support. It is capable of running a pre-emptive real time operating system like

Linux (xenomai) and a full featured network stack that allows the developer to access a pool

of ready to run software applications. In particular the board can run an SNMP agent, a WEB



server and different processes to control the devices forming the system. The operating system

is capable of managing hard real time events.

The full version of the current ODU Hardware architecture is depicted in Figure 4.2.

Figure 4.2 ODU Hardware Architecture (full version)

The current ODU board Hardware details are listed below:

Freescale MPC880 PowerQUICC

The main functional control blocks are:

- Microprocessor (uP) manages the ODU card, handles alarms, handles the

protection switch protocol and communicates with a remote Element Manager,

a Local Craft Terminal and the ODU partners (local and remote);

- Memory and Peripherals, e.g. SDRAM, Flash EPROM (serial and parallel),

FPGA and other devices used for management of RF channel.

LATTICESEMI LFE2M35E-5F256C FPGA (Ethernet Layer 2 Switch + MODEM

functionalities)

The Switch performs the following functions:

- Routing of LCT controller messages based on MAC address and optionally on

VLAN tag.

- Routing of CT traffic from/to Cable Interface to/from INT A of Modem, based on

proprietary VLAN tag. No buffering (unless the one required for the store&forward

mechanism) and flow control is applied to this traffic between Switch and Modem.

When the radio channel is not available the traffic is dropped.



- Routing of DUT (Data User Traffic) from/to Cable Interface to/from INT B of

Modem, based on MAC address and optionally on VLAN tag. This traffic to the

radio link can be served by four priority queues to implement QoS, based on IEEE

802.1p, IP TOS&DS, VLAN ID and MAC address. Because of the limited capacity

available on the radio link, on INT B a PAUSE Flow Control is applied to stop

forwarding frames from Switch to Modem when the Modem Tx buffer is full. The

incoming messages from the Cable interface are buffered in the Switch priority

queues according to VLAN tag. The queues are emptied according to their priority.

When the queues are full the following messages are discarded.

- Routing of Management information from/to System controller to/from INT B of

Modem (radio channel), based on MAC address and optionally on VLAN tag.

Memories:

o 32-bit-wide 64 Mbyte DDR3 SDRAM for data handling and program execution

o 32 MByte NOR Flash memory for SW code and FPGA netlist

o 1MB Serial Flash EPROM for station data

Parallel and serial busses to/from memory and peripheral devices:

o microprocessor local bus at 66 MHz to demultiplex address, data and control

lines required to access SDRAM, Flash EPROM, FPGA and other devices

o SPI bus required to access the external serial Flash EPROM for station inventory

data and some RF section’s devices.

o I2C bus required to access some devices used into the RF section.

The Serial Management Controller is used as a Debug Serial Interface for HW and SW

debugging purposes.

4.1.2 The new platform

Because there is already a current baseline implementation of the demonstrator running on

MPC880 hardware, the main Intecs goal within CONTREX is to provide a basis to extend the

company know-how in the CONTREX innovation domains (in particular the virtual platform

and power estimation domains) in order to integrate them into future product development

processes.

The Telecom Use case platform model is fully explained in Section Fehler! Verweisquelle

konnte nicht gefunden werden., and it is mainly focused on the Open Virtual Platform

environment exploitation. Moreover, Intecs is interested in cross-verification of the results

obtained using the virtual platform and the power/thermal tool-set. For that reason, Intecs

intends to port its current implementation of the Ethernet Over Radio application to a real Zynq

board (Zynq-7000 XC7Z045 FFG900 – 2), depicted in Figure 4.3.



Figure 4.3 Telecom demonstrator real board - ZC706 board features

:

Note: The consortium proposed platform for the OVP modelling was the Xilinx Zynq 7020

SoC XC7Z020-1CLG484C – nevertheless, we do not expect significant differences

between the two platforms in terms of component modelling within the Open Virtual

Platform environment.

The Zynq-7000 XC7Z045 FFG900 – 2 platform has the following key features Fehler!

Verweisquelle konnte nicht gefunden werden.:

Configuration

Onboard configuration circuitry

2X16MB Quad SPI Flash

SDIO Card Interface (boot)

PC4 and 20 pin JTAG ports

Memory

DDR3 Component Memory 1GB (PS)

DDR3 SODIM Memory 1GB (PL)

2X16MB Quad SPI Flash (config)

IIC - 1 KB EEPROM

Communication & Networking

PCIe Gen2x4

SFP+ and SMA Pairs



GigE RGMII Ethernet (PS)

USB OTG 1 (PS) - Host USB

IIC Bus Headers/HUB (PS)

1 CAN with Wake on CAN (PS)

USB UART (PS)

Video/ Display

HDMI 8 color RGB 4.4.4 1080P-60 OUT

Expansion Connectors

1st FMC LPC expansion port (34 LVDS Pairs on LA Bus, 1 GT)

2nd FMC HPC expansion port (34 LVDS Pairs on LA Bus, 8 GT – No HA or HB bus)

Dual Pmod (8 I/O Shared with LED’s)

Single Pmod (4 I/O)

IIC access to 8 I/O

Clocking

33MHz PS System Clock

200MHz PL Oscillator (Single-Ended Differential)

SMA Connectors for external clock (Differential)

GTX Reference Clock port with 2 SMA connectors

OBSAI/CPRI – SFP+ Received clock

EXT Config CLK

Control & I/O

2 User Push Buttons/Dip Switch, 2 User LEDs

IIC access to GPIO

SDIO (SD Card slot)

3 User Push Buttons, 2 User Switches, 8 User LEDs

IIC access to 8 I/O

IIC access to a WTClock

Power



12 V wall adaptor

Current measurement capability of supplies

Analog

AMS interface (Analog) System Monitor and also available for external sensor

4.2 Telecom demonstrator platform models

The platform models used for the demonstrator will constitute an abstracted version of the ODU

suitable for demonstrating the functioning Telecom application (described in D4.1.1) making

use of the CONTREX innovation technologies.

The demonstrator platform models for the Telecom demonstrator are depicted in the indicated

area in Figure 4.4, providing support to the demonstrator application.

Figure 4.4 Demonstrator platform modelling for UC3

EDALab is considering the processing of UML/MARTE models for use in system level DSE

with SCNSL, providing network simulation / modelling functionality to the demonstrator

platform.

The primary demonstrator platform model is envisioned to be the Open Virtual Platform, which

will host the chosen Zynq platform being used as widely as possible throughout the consortium

in order to provide useful comparative implementation experiences across the use case. At the

Legacy HW/SW Model

Time critical

SW

SDFsModeling and Analysis

Virtual Platform (OVP)

HW

(C/C++/SystemC)

SW

Functional/Extra-functional

SimulationTestbench (SCNSL)

ForSyDe model

Design validationActual HW SW Package

description

Power

(datasheet)

Radio channel

EthernetPower

model

Thermal

model

Exec time

measurements

Power

measurements

Target Platform (ZYNQ)

HW in the

loop facility

HW abstraction

(HIFSuite) SW synthesis

(HIFSuite)

SWHW (SystemC, VHDL,

Verilog, IP-XACT)

Time critical SW

Analytical

DSE for Timing

Simulation-based

DSE for Power

and Temperature



time of this delivery (Month 18), investigations are being completed into the choice of final

simulation hosting environment, originally postulated to be an implementation provided by

partner OFFIS but which could potentially shift to a Cadence offering.

OFFIS is preparing a critical part of the Telecom demonstrator platform modelling

environment, the OVP plugin that will generate power and thermal traces from the simulation

for subsequent offline input to the modelling tools provided by both Docea and OFFIS for

(offline) analysis and optimization of thermal and power related properties.

Note that the Telecom demonstrator does not include a full-blown runtime modelling

component in the same sense as in the other use cases, since the principal business case for the

modelling activities is in the design of the new generation of Intecs telecom product lines and

services rather than dynamic run-time monitoring of an operational system. The emphasis is

therefore on maximizing the simulation and trace generation capability, for use in extensive

offline analysis of extra-functional characteristics, which feed back not so much into dynamic

runtime reconfiguration but rather design time architecture (aided by the application system

modelling innovations of CONTREX treated in the companion deliverable D4.1.1).



5 References

[1] "Description of Work". CONTREX – Design of embedded mixed-criticality

CONTRol systems under consideration of EXtra-functional properties, FP7-ICT-

2013- 10 (611146), 2013.

[2] Xilinx Inc. (2014) Zynq-7000 Platform Devices. [Online]. Available:

http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/index.htm

[3] Trenz Electronic GmbH. (2014) Trenz Electronic TE0720 Series. [Online]. Available:

http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0720-

zynq.html

[4] “Cadence Virtual System Platform”.

http://www.cadence.com/products/sd/virtual_system/pages/default.aspx

http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/index.htm

http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0720-zynq.html

http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0720-zynq.html

Design of embedded mixed-criticality CONTRol systems … · CONTREX/STM/R/D4.2.2 Public...

Documents

Transcript of Design of embedded mixed-criticality CONTRol systems … · CONTREX/STM/R/D4.2.2 Public...