Platform System Architecture 2nd Release

Transcription

1 Platform System Architecture 2nd Release Deliverable n. D Platform System Architecture (Second Release) Sub Project SP2 ADAS development platform Workpackage WP2.5 Platform System Architecture Tasks T2.5.1 T2.5.2 Hardware architecture Software architecture Authors Frank Badstübner Ralf Ködel, Wilhelm Maurer Martin Kunert André Rolfsmeier Joshué Pérez F. Giesemann, G. Paya Vaya, H. Blume Gideon Reade Infineon Technologies AG Robert Bosch GmbH dspace GmbH INRIA IMS ASL File name D25.2_Platform_System_Architecture_- _Second_Release_IFAG_Final Status Final, v0.5 Distribution (RE) Issue date 31/08/2014 Creation date 04/10/2014 Project start and duration 1 st of September, months

2

3 REVISION CHART AND HISTORY LOG Ver DATE AUTHOR REASON Frank Badstübner Table of contents and document structure created, IFAG contributions and content from first release integrated Pier Claudio Antonello CRF contributions added: Added in 2.1: rapid prototyping architecture instance in WP4.1 WP4.2 and WP4.3; Added 3.2 Application Software Modules Gideon Reade ASL contributions added Hans Deragarden Volvo contributions added André Rolfsmeier dspace contributions added, chapter 2.1 reviewed F. Giesemann, N. Mentzer, H. Blume (IMS) Added evaluation results for ADTF and FGPA based development Frank Badstübner dspace and IMS contributions added, consolidated version generated Frank Badstübner Final version generated Frank Badstübner Reviewer comments considered. Final version generated for submission Page 3

4 TABLE OF CONTENTS REVISION CHART AND HISTORY LOG... 3 TABLE OF CONTENTS... 4 LIST OF FIGURES... 6 LIST OF TABLES... 7 LIST OF ABBREVIATIONS... 8 EXECUTIVE SUMMARY INTRODUCTION Objective and scope of this document Structure of the deliverable HARDWARE ARCHITECTURE Flexible, modular and scalable rapid prototyping platform Rapid prototyping architecture for inter-urban assist (WP4.6) Rapid prototyping architecture for WP Rapid prototyping architecture for ACC with autobrake truck application High speed low latency communication bus Transfer of prototyping functionality into next generation MCU RADAR HW accelerator (signal processing unit) Simulink model Vision pixel preprocessor Simulink model Transfer of Prototyping functionality into Next Generation ECU FPGA-based platform to emulate hardware modules Testing process for the hardware architecture SOFTWARE ARCHITECTURE Specification of the software architecture Application Software Modules Concepts for client-server access Page 4

5 3.4. Multi-task option to permit adding and removing of functionalities Hardware optimized software functionalities Motivation for the DSP library Function naming convention Calling convention Target Function list Use of ADTF together with FPGA based development platform CONCLUSION REFERENCES ANNEX A Page 5

6 LIST OF FIGURES Figure 1: DESERVE approach use of common platform for all ADAS modules Figure 2: DESERVE rapid prototyping architecture with three development levels (Level 1: PC based development frame work, Level 2: Embedded Controller frame work, Level 3: Dedicated Hardware Accelerator framework) Figure 3: Generic hardware architecture of DESERVE development system Figure 4: DESERVE rapid prototyping architecture for WP4.6 inter urban assist Figure 5: DESERVE rapid prototyping architecture for WP4.1, WP4.2 and WP Figure 6: HW platform for in-vehicle test Figure 7: DESERVE rapid prototyping architecture for ACC with autobrake Figure 8: ACC with autobrake functional architecture Figure 9: Architecture of an x86 processor based prototyping system Figure 10: I/O access with flow control processors Figure 11: Architecture of a high speed low latency bus interface Figure 12: RADAR hardware accelerator Simulink model Figure 13: Vision pixel processing model Figure 14: FPGA-based platform with the DESERVE development system Figure 15: DESERVE platform architecture Figure 16: Open CV functions Figure 17: OSI seven layer model for computer network communication Figure 18: Overview on the principles of virtual interaction using the AUTOSAR Figure 19: DESERVE Platform splitting Figure 20: External bypassing and client-server communication Figure 21: Service based bypassing extended by a concept for client-server access Figure 22: Overview of an exemplary sign detection algorithm Page 6

7 LIST OF TABLES None Page 7

8 LIST OF ABBREVIATIONS ABBREVIATION DESCRIPTION ACC Adaptive Cruise Control ADAS Advanced Driver Assistance System ADTF Automotive Data and Time-Triggered Framework AEB Autonomous Emergency Braking API Application programming interface ASIL Automotive Safety Integrity Level AUTOSAR AUTomotive Open System ARchitecture CFAR Constant False Alarm Rate CPU Central Processing Unit CV Computer Vision EABI Embedded Application Binary Interface FIFO First In First Out (equivalent to first come, first served) FPGA Field Programmable Gate Array GI Generic Interface GigE Gigabit Ethernet HIL Hardware In the Loop Page 8

9 HMI Human Machine Interface HW Hardware IMS Institute of Microelectronic Systems ISO26262 ISO is a Functional Safety standard, titled "Road vehicles -- Functional safety". Functional safety features form an integral part of each product development phase, ranging from the specification, to design, implementation, integration, verification, validation, and production release. ISO defines functional safety for automotive equipment applicable throughout the lifecycle of all automotive electronic and electrical safety-related systems. IWI Information Warning Intervention MCU Microcontroller Unit (here with focus on multi-core processors) NVRAM Non-Volatile RAM OpenCL Open Computing Language OpenCV Open Source Computer Vision Library OSI Open Systems Interconnection (Model) PC Personal Computer PIL Processor In the Loop POSIX Portable Operating System Interface PWM Pulse Width Modulated RTE Run-Time Environment RTOS Real Time Operation System Page 9

10 SoC System on Chip SPU Signal Processing Unit SW Software VFB Virtual Function Bus Page 10

11 EXECUTIVE SUMMARY The basic idea and intention of the DESERVE project is to standardize the interfaces between the three different development levels as far as possible: Level 1: PC-based development framework Level 2: Embedded controller development framework Level 3: Dedicated hardware (e.g. ASIC / accelerator) development framework Depending on the performance of the PC in best case all or typically only specific parts of the SW modules are executed in level 1. During the development process more and more SW parts are transferred to the HW-Accelerator level 3, which, in the final development stage, results in the next generation embedded ADAS target system. This deliverable focuses on the overall platform system architecture and addresses following key hard- and software topics: Chapter 2 concentrates on the hardware requirements and architecture topics including the need for a flexible, modular and scalable rapid prototyping platform, the high speed, low latency communication bus (e.g. Gbit Ethernet), the transfer of prototyping functionality into next generation MCU (supported by modelling of radar hardware accelerator and vision pixel pre-processor in Simulink) down to an FPGA-based platform to emulate the hardware modules, and finally considering the testing process. Chapter 3 is dedicated to aspects concerning the software architecture of the platform system. The software architecture is defined, concepts for client-server access are described, a multi-task option to permit adding/removing of functionalities is presented. Additionally, the way to achieve hardware optimized software functionalities is proposed (including the use of DSP library and the agreement on naming and calling conventions). Finally, the use of the ADTF platform (from level 1 down to FPGA level 3) is explained Page 11

12 1. Introduction 1.1. Objective and scope of this document The objective of this deliverable is to describe the second release of the platform system architecture. D25.2 is the first of a series of deliverables documenting the work performed to define the second release of the platform system architecture serving as the processing platform for ADAS systems: D25.2 Platform system architecture 2 nd release D25.4 Standard interfaces definition 2 nd release D25.6 Guidelines for applications 2 nd release and D25.8 DESERVE platform 2 nd release 1.2. Structure of the deliverable D25.2 covers the different relevant hardware architecture aspects (chapter 2 refers to task 2.5.1) and software architecture aspects (chapter 3 refers to task 2.5.2) of the platform Page 12

13 2. Hardware architecture DESERVE has to be flexible enough to be implemented in a distributed and scalable architecture (several modules, each of them able to sense and/or process and/or actuate) or a concentrated one (sensors and actuators all linked with a single unit of processing and control). Task identifies which conditions have to be satisfied by the individual subsystem architectures in order to be compliant with the DESERVE generic hardware platform. For maximum reusability the DESERVE concept and hardware architecture has to be designed in such a way that subsystems of different generations (or respectively the kernels of it) can be used in parallel, thereby enabling the rapid and effective creation of next-generation innovative ADAS systems by using well tested and certified kernel functions of the old system which partly could be already implemented as SoC (System on Chip). The DESERVE development platform can be seen as a flexible rapid-prototyping environment that enables fast and efficient development of nextgeneration ADAS functions in a continuous iteration cycle between the current and nextgeneration embedded subsystem components. Furthermore, the DESERVE concept has to be flexible enough for different DESERVE partners to make different implementations. These would be of forms that might in future be interoperable, although DESERVE will not attempt to define detailed standards which would be necessary for actual interoperability. The main DESERVE idea concerns the use of one common platform system (Figure 1) for all ADAS functional modules, instead of the current approach to have one platform for each individual ADAS system. Basically, three main hardware architecture challenges arise from this idea: Automotive quality: The platform needs to provide high reliability over the complete automotive temperature range, power supply and environmental conditions. As ADAS systems address safety aspects, the platform should implement as far as possible the ISO requirements, i.e. at least the hardware components that are near to the final product unit shall support the required ASIL level Page 13

14 For PC-based platform components the typical commodity specifications shall be reached as a minimum and, where possible, extended requirements should be applied. Figure 1: DESERVE approach use of common platform for all ADAS modules Possibility to extend hardware capabilities: The platform needs to be designed upfront to support the possibility to include additional hardware into the system. Standard sensor interfaces are needed, for instance, but also standardized interfacing to external FPGA/DSP for performance enhancement is required. For scalability purposes, such external devices need to be cascadable. Similar considerations hold for the memory interface capability Page 14

15 A special case of hardware extension capabilities is the reuse of serial parts from earlier generations to speed up the development process or to increase the sensor perception by placing more sensors on the car. Finally, a seamless environment tool chain is needed. One key requirement lies in the reuse of the existing tool ecosystem over several platform generations. Further, we should target adaptability of the tools to the broad industry use cases, e.g. next generation video and radar sensors. Additionally, real-time monitoring and debugging of interface and processing for development purposes represent key challenges. Although the DESERVE objective is a common platform, for the actual implementations within the DESERVE timescale, there are multiple possible implementations. These draw from the same concepts, and to some extent a common parts bin, but in DESERVE s timescale each will only support interoperability within some collaborating subgroup. These are roughly grouped around demonstrators, e.g.: Daimler/Bosch/Infineon/dSPACE Inter-urban assist (WP4.6) CRF/Inria/Intempora Warning functions (WP4.1), control functions (WP4.2) and vulnerable road user protection functions (WP4.3) Volvo/ASL/Intempora ACC with autobrake truck application (a DESERVE interface is needed at the interface between ASL s Perception Platform implementation, and Volvo Truck s Application Platform). Other non-demonstrator partners 2.1. Flexible, modular and scalable rapid prototyping platform The DESERVE development platform architecture needs sufficient flexibility, modularity and scalability to cope with the steadily increasing complexity and calculation power request of the high-sophisticated algorithms of the perception, evaluation and reasoning modules. The fundamental challenge lies in the demanding antagonism to provide more and more calculation power in always shorter time, with the boundary condition of maximum reuse of the preceding generation concepts and hardware components Page 15

16 The basic requirements for the architecture of the DESERVE rapid prototyping platform can be expressed in the following bullet points: 1) Enough flexibility to encompass different development environments in a common, seamless framework for both the high-level algorithm development and the easy porting of these SW modules to the embedded target platform. 2) Real time recording and playback capabilities for both the high-level and embedded system implementations. 3) A communication architecture that is capable to shift SW portions from the highlevel development side to the embedded target system as required (i.e. bypassing with HW accelerators). 4) A seamless interoperability and replacement between the high-level (i.e. PCbased) and embedded target systems both for development and validation purposes. It is obvious that many of the demanding algorithms cannot be run in realtime on a universal PC-based platform, because several data streams with Gigabit transfer-rates from video and radar sensors have to be processed. For this task dedicated hardware accelerators have to be used to squeeze down the information flow to a manageable dimension. The programming of such dedicated hardware components is still burdensome due to a lack of efficient, automatic coding tools. This is in strong contradiction to the typical research and development process, where in the start-up phase the software code is still in an early experimental stage with many changes and software parts that are sometimes completely off the track. In this software pioneering phase the expensive hand-coding of very specific one-time code is unproportional and difficult to justify. The compromise can be found in a compound approach where for each part in the product development cycle the appropriate measures are available. For research and early product development well-established software tools like Matlab/Simulink or ADTF are available. What is missing is the development framework for seamless transition from high-level software tools to very specific hardware coders for embedded systems. The idea and intention of the DESERVE project is to standardize the interfaces between the three different development levels as good as possible: Page 16

17 Level 1: PC-based development framework Level 2: Embedded controller development framework Level 3: Dedicated hardware (e.g. ASIC) development framework As the platform is intended to be flexible, it should also be able to work with variations on this hardware progression Rapid prototyping architecture for inter-urban assist (WP4.6) The three development levels are shown in Figure 2 for the DESERVE demonstrator interurban assist (WP4.6). ADAS Inputs: Radar Sensor PC based development framework WIN7 / Matlab& Visual C++ GI2 Embedded Controller framework dspace RCP / TargetLink&VHDL NIR Camera1 GI1 GI3 NIR Camera2 Navigation PI1-4 Breakout Box CAN LVDS LVDS CAN/ADASISV2 HW Accelerators dedicated ASICs (e.g. from last generation or newly designed) Legend: PI = private interface GI = genericinterface RCP = Rapid-Control-Prototyping LVDS = low voltage differential signal Figure 2: DESERVE rapid prototyping architecture with three development levels (Level 1: PC based development frame work, Level 2: Embedded Controller frame work, Level 3: Dedicated Hardware Accelerator framework) Inputs from proprietary ADAS sensor systems and information sources are analyzed and sent via a generic interface GI1 to the PC based development environment. Here the Page 17

18 ADTF tool with its filter programming concept is used to develop or improve SW modules on a high-level programming language with lowest programming effort and in shortest time. RTMAPs could represent a suitable alternative. For the WP4.6 demonstrator partners involved agreed to work with ADTF. The partitioning and optimization of parts of the SW modules is consecutively done by shifting such portions over the generic interface GI2 to the embedded controller framework that is already much nearer to the final commercial product. Via this bidirectional interface bypassing techniques like PIL (embedded Processor In the Loop) can be realized. In a final step, dedicated HW accelerators can be linked in via the generic interface GI3 by applying the same bypassing concept again. Especially computationally intensive tasks can so be outsourced, so that even the PC-based platform is capable to keep the stringent real-time constraints. Depending on the performance of the PC in best case all or typically only specific parts of the SW modules are executed in level 1. During the development process more and more SW parts are transferred to the HW-Accelerator level 3, which, in the final development stage, results in the next generation embedded ADAS target system. In this last development step, the level 1 (PC) and level 2 (embedded Controller) platform will only serve as a shell to keep up the overall development framework. Already existing components from former ADAS generations may be re-used in the early development phase as hardware accelerators for computational intensive calculations. Mainly standard algorithms that are fixed and obtain no further modifications over time are preferred candidates for such specific accelerator implementations. The generic hardware architecture developed in WP2.1 is shown in Figure 3. This architecture reflects the three development levels described above Page 18

19 Figure 3: Generic hardware architecture of DESERVE development system In Figure 4 the hardware architecture concept for level 1 (PC-based) and level 2 (embedded controller) development stages for the inter-urban assist demonstrator of WP4.6 is sketched. Figure 4: DESERVE rapid prototyping architecture for WP4.6 inter urban assist Page 19

20 The importance of well-defined and standardized interfaces between the particular components and modules is striking. For the high speed interfaces GI1, GI2 and GI3 (see Figure 2) Gigabit Ethernet (GigE) is the preferred candidate. Special interface hardware boxes for connecting proprietary (sensor) interfaces to already standardized communication protocols are sometimes needed Rapid prototyping architecture for WP In Figure 5, the hardware architecture concept for level 1 (PC-based) and level 2 (embedded controller) development stages for the passenger car demonstrator and WP4.1, WP4.2 and WP4.3 is shown. The following functions will be developed and integrated in the DESERVE platform: AEB pedestrian, AEB inter-urban, driver distraction, driver intention. These applications are partially based on already existing sensors and partially on new generation one s. All sensors are acquired by powerful and flexible PC based hardware. The common rapid prototyping tool for development of the perception platform and the data fusion is RTMaps. But the platform also includes an embedded controller (MicroAutoBox) where, during development, high level application software, vehicle control models and HMI manager (IWI) will be transferred and tested. PC (Level 1) and microcontroller (Level 2) are connected by Ethernet bus. Currently, the use of Level 3 (Dedicated Hardware Accelerator) is not foreseen, even if the HW platform includes FPGA board for future developments (Figure 6) Page 20

21 Figure 5: DESERVE rapid prototyping architecture for WP4.1, WP4.2 and WP4.3 Figure 6: HW platform for in-vehicle test Page 21

22 Rapid prototyping architecture for ACC with autobrake truck application The commercial vehicle demonstrator will be based on collaboration of Volvo, ASL and Intempora. A variation on Figure 4 is to push the use of ADTF or RTMaps further across the system. This further standardizes the interfaces between the boxes (to a higher level in the protocol stack). This is feasible where the HW Box (supplier proprietary) above supports a Linux kernel, as for RTMaps at least, the middleware runtime can then be run at the sensor units. Sensors with Ethernet are allowed, but not running the middleware runtime, to participate in the middleware s external protocol: In such cases the sensor would appear in Figure 3 as a separate ADTF filter or RTMaps component, rather than as an input to a composite one. One of these two approaches is intended for the Volvo Trucks demonstrator. This system (Figure 7) is to be composed using two of the three hardware platforms listed above. ASL will be using, effectively, a production ECU, whereas Volvo will be using a combination of automotive computers. These will be interconnected using Ethernet as the low level transport, with RTMaps as middleware. ASL s preferred approach would be to actually run the RTMaps runtime on the ASL ECU (which runs Linux); this would mean ASL did not even need to know what level of Ethernet protocol RTMaps used. However, time may not permit this, and ASL will probably have to produce a simple protocol component on the ECU, which can connect to the RTMaps Ethernet interface on Volvo s PC. The data form and content of the data passed from ASL s virtual sensor to Volvo s application would be a one-off separate partial DESERVE interface, along the lines discussed in WP25.4 specification. It would be expected to be approximately similar to Daimler / Bosch s interface, but not actually compatible as DESERVE partners are not generally sharing down to a low enough level to do that. The functional architecture for this, the ACC with autobrake demonstrator, is depicted in Figure Page 22

23 Figure 7: DESERVE rapid prototyping architecture for ACC with autobrake Figure 8: ACC with autobrake functional architecture Page 23

24 2.2. High speed low latency communication bus As outlined in chapter 4.4 of [12] the performance of the internal communication bus to interface the processor and the associated I/O units is essential for a universal development platform. Figure 9 illustrates the proposed architecture for an x86 processor based prototyping system. The following requirements have to be addressed by the communication bus: Short latency times (in the range of a few microseconds) associated with the complete processing sequence consisting of capturing input signals by an I/O unit, triggering the associated processing task on the x86 processor and writing the resulting output signals by the same or another I/O unit Latency times are virtually independent of the number of input and output channels High data throughput (in the range of one Gbit/s) No limitation by the bus architecture concerning the number of I/O units which can be connected to the x86 processor Time synchronization of I/O units accurate to about 0.1 microseconds so that the associated data is captured and output exactly at the same point of time Event synchronization of I/O units allowing input data to be sampled and outputs to be written exactly at the same event, e.g., at the same crankshaft angle accurate to 0.1 degrees Support of up to 16 individual real-time tasks per I/O unit Option to connect I/O units in a centralized and decentralized way and to bridge distances of tens of meters High noise immunity of the communication bus Support of single and block read/write access Page 24

25 Figure 9: Architecture of an x86 processor based prototyping system At first sight, PCI Express (PCIe, [13]) might be the communication bus of choice when using x86 processors. However, several requirements listed above are not directly met by PCIe. Instead, a new high speed communication bus is proposed for a modular DESERVE platform. Figure 10 illustrates the typical flow of data related to a real-time task in which I/O units are accessed. In common prototyping scenarios several of these tasks, timer and/or event-driven, run in parallel. The software modules mentioned in this figure stand for dedicated sub-systems of the associated simulation model. To guarantee consistent data it is essential that all inputs are read (RI) and all outputs are written (WO) exactly at the same point of time no matter at which positions the respective I/O blocks are used in the model and how many and what kind of I/O units actually are accessed. Research work has shown that a dedicated flow control processor is required for this allowing I/O specific code to be executed Page 25

26 Figure 10: I/O access with flow control processors The I/O access with the flow control processor is described in the following: 1. A timer or an external event triggers both a task on the x86 processor and the I/O program on one or multiple I/O units exactly at the same time (1). 2. The I/O program reads the input data and sends matching data packets via the communication bus to the processor. 3. During the calculation of software module 1, output data is send via the communication bus to program At the end of software module 1, an output event TO is generated causing the program 2 to write all I/O outputs at once (2). 5. The steps 3 and 4 recur with software module m and output event (3) triggers program 3 The program 1, 2 and 3 may run on the same flow control processor as I/O data is processed sequentially in the corresponding real-time task. Further details about the new communication bus are shown in Figure 11 ( network to connect architecture levels 1 and 2 presented in Figure 2). The flow control processors are implemented in an FPGA allowing multiple instances to operate completely in parallel. This way, for example, a rising edge of a PWM signal can be used to trigger data capturing via ADCs without burdening the x86 processor Page 26

27 Figure 11: Architecture of a high speed low latency bus interface The major part of the conceptual design was the specification of the flow control processor in the FPGA and of a reduced instruction set to meet the demanding performance goals. This reduced instruction set is listed below: Input / Output Operation LOAD sx 3, {cy 32, sy 3 } (load constant or register into register) INPIO sx 3, ay 30 (read word from I/O address to register) INPMEM sx 3, ay 13 (read word from memory address to register) OUTPIO sx 3, ay 30 (write register content to I/O address) OUTPMEM sx 3, ay 13 (write register content to memory address) Logical Operation AND sx 3, {cy 32, sy 3 } OR sx 3, {cy 32, sy 3 } XOR sx 3, {cy 32, sy 3 } Basic Arithmetic {ADD,SUB} sx 3, {cy 32, sy 3 } Page 27

28 {SHR,SHL} sx 3, {cy 32, sy 3 } Advanced Arithmetic MUL{HI,LO} sx 3, {cy 32, sy 3 } Program Control JMP cx 10 JMP{Z,NZ} cx 10 JMP{C,NC} cx 10 NOP COPY Operation MEMCPY n 8, ax 30, ay 13 (copy n words from I/O [ax] to memory [ay]) 2.3. Transfer of prototyping functionality into next generation MCU Infineon is developing a Simulink model to implement two numerically intensive algorithms on next generation multi-core micro controller units (MCU), e.g. AURIX platform. The focus is based on smart hardware acceleration of RADAR (see details in 2.3.1) and Vision (see 2.3.2) sensor signal processing algorithms. Next generation MCUs represent hardware accelerators corresponding to architecture level 3 presented in Figure 2. Their use will allow an optimized overall system set in terms of power consumption and size RADAR HW accelerator (signal processing unit) Simulink model Figure 12: RADAR hardware accelerator Simulink model Page 28

29 a) Simulink Model Project description The main goal is to design a Simulink model of the Radar Signal Processing Unit for AURIX 1 in order to: enable customer activities, e.g. evaluation of CFAR (constant false alarm rate) algorithms, advanced prototyping by running a model in a PC and demonstration enable internal activities including IP specification verification for designers and subcontractor b) SPU Simulink model deliverable The model of the signal processing unit (SPU) will be provided as an encrypted sfunction to enable executable demonstrations. c) SPU Simulink model milestones Two steps are introduced to monitor progress: step1: IP Simulink model development step2: demo software within Simulink 1 AURIX is Infineon s new family of microcontrollers serving the needs of the automotive industry in terms of performance and safety. Its multicore architecture, based on up to three independent 32-bit TriCore CPUs, has been designed to meet the highest safety standards while increasing the performance at the same time. Using the AURIX platform, automotive developers are able to control powertrain, body, safety and ADAS applications with one single MCU platform. Developments using AURIX will require less effort to achieve the ASIL-D standard than with a classical Lockstep architecture. Customers are now able to cut down their MCU safety development. By the same token, a performance surplus allows for more functionality and offers a sufficient resource buffer for future requirements, keeping the power consumption on the single-core microcontroller level Page 29

30 d) Model scope The scope of the model is to simulate computations and the data produced by RADAR Signal Processing Unit. There is no intent to simulate execution and transfer times. e) Model principle The principle of the model is to generate results in the form of data sets (or data structures). To allow verifying the behavior of various IPs the data set granularity should be per IP. So, when starting a new acquisition sequence, the data structures are initialized. Then, during the acquisition sequence, the data sets are generated and/or updated according to the command and the processing step. f) Safety aspects The model is intended to be used at early stages of customer projects. It is not intended to be used as reference model for non-regression testing of production SW. g) Model verification The model is being designed at Infineon. It is proposed that the verification is conducted in Infineon to have independent verification. Customer delivery should be done only after verification. RADAR signal stimuli: It is proposed to use data collected using an already available 77GHz RADAR demonstrator. Test cases: dedicated use cases should be done per possible SW configuration. h) Executable demo The analysis of the project is showing that additional Simulink blocks will be required to generate stimuli to the RADAR SPU. One identified additional block is the RADAR State Machine that is generating a ramp index and the antenna index to the RADAR SPU. MCU/CPU model: It is not intended to model the TriCore or AURIX. At the end, the TriCore is executing C code and this is what needs to simulated Page 30

31 Vision pixel preprocessor Simulink model The Pixel preprocessor is made of different execution units in parallel where each of them can be enabled /disabled, has its own output FIFOs and address range into the shared video memory (the EMEM ) and runs from the system clock (up to 300MHz). Main purpose is to enable specific pixel processing to reduce performance and RAM requirements to enable reduced power consumption and heat anticipation. Figure 13: Vision pixel processing model The key features are: Image region extraction o Up to 5 user run-time defined regions o 1 secondary path allow MJPEG compression without CPU load Configurable down-sampling for main path M-JPEG compression unit (no CPU load) Integrated safety watchdog o Monitoring of SYNC signals from sensor Powerful memory interface Page 31

32 o Each path has its own buffer and its own interrupt o DMA interface to main RAM Full debug support from any path o Selected path can be copied to debug interface o CRCs protecting payload and header information 2.4. Transfer of Prototyping functionality into Next Generation ECU Some ADAS ECUs will be expected to run multiple ADAS functions at the same time. These ECUs can deploy relatively powerful & flexible operating systems so that production systems can dynamically switch features on and off according to the driver s requirements. Effectively, they can be like a node of almost desktop-like flexibility, within the vehicle, but on a production vehicle completely isolated from the rest of the world except for a tightly controlled AUTOSAR gateway. With no or little change to production builds they well support, in particular, Ethernet. These production, or slightly enhanced, ECUs can be deployed as a development platform, either singly, or in an array. These platforms are also very capable of running basically the same ADAS function implementations in C/C++ as laboratory PCs. Ideally, such a development hardware can directly run the runtime environment of ADTF or RTMaps. Less optimally, it can interface to their public interfaces. In a production vehicle, these ECUs are expected to run multiple ADAS functions concurrently and at full vehicle speed. For development each ECU can run a reduced load, of one or a few, non-concurrent functions. Functions under test can therefore be less optimized and with extra test features. Communication between ECUs in this arrangement would by default be via Ethernet. Ethernet does not provide a QoS guaranteed and very low-latency link (see discussion of dedicated buses elsewhere in this document), but it has flexibility & bandwidth and is quick enough for many of the lower speed ADAS functions such as parking Page 32

33 This approach allows early access to real hardware capabilities and real optimized versions of libraries such as Infineon s discussed in his document. It can also support decisions about future hardware, if ECUs as examples of possible targets exist FPGA-based platform to emulate hardware modules The FPGA-based development platform can be used to emulate different hardware modules that perform different signal processing operations. The modules can be implemented independently and can be easily added to the generic bus-based platform. This allows a modular construction of different complex driver assistance algorithms and applications by interchanging the different hardware modules. The modular concept increases the possibility for reusing existing modules in different projects and can therefore lower the development time. It also allows characterizing the single hardware modules by quantitative cost models, which can guide the development process towards hardware and cost efficient implementations. The architecture of the FPGA-based platform associated with a specific DESERVE development system is outlined in Figure 14. The FPGA board includes a powerful Xilinx Kintex-7 FPGA allowing several signal processing blocks for perception algorithms to be integrated. Moreover, the FPGA provides high speed connectivity by means of a Gigabit Ethernet connection to PCs. Finally, the FPGA board supports up to 4 GB DDR3 RAM memory so that even demanding applications, for example for processing video or radar data, can be implemented Page 33

34 Figure 14: FPGA-based platform with the DESERVE development system A flexible and modular AXI bus infrastructure (AXI bus, [10]) is used as a template for any FPGA hardware design. This template can be expanded with new signal processing blocks by connecting these blocks to the bus. The FPGA board also allows the integration of real hardware-accelerators. For example, a radar front-end may directly be connected to the FPGA using a dedicated piggy-back module and the actual radar logic is implemented in the FPGA. It is even possible to directly interface a target microcontroller such as Infineon AURIX. Further details are provided in the DESERVE deliverable D2.1.2 [14] Testing process for the hardware architecture The validation of the hardware architecture (including electronic operation) can be defined as a set of specifications defining test methods for diverse components. This process should guarantee that the hardware is as stable as possible, in order to reduce possible failures in the performance of the system Page 34

35 The reliability of ADAS systems is a necessity of the human safety. Therefore, testing ADAS systems is a very important task which can prevent human errors and material problems in the driving process, due to hardware or software failures. The testing of ADAS systems allows evaluating the compliance of these systems with their specified requirements. The standard ISO 26262, for the functional safety of automotive electronics systems, provides a good guidance on establishing safety requirements for their electronics systems, performing hazard and risk assessments for embedded systems. A recent report of the National Research Council (U.S.A) describes some the most important challenges of electronics safety assurance in modern vehicles [1]: Electronics are central to the basic functionality of modern automobiles. o Growing of interconnectivity (devices and networks external to the vehicle). o Benefits on motorists (Safety). To improve safety, fuel economy, emissions, and other vehicle performances. o Depend on real-time coordination. Hardware will require dependability assessments o Further increases in software complexity. o New sensors technologies. Based on the procedure proposed in [1], the testing process for the hardware architecture in DESERVE will be defined as follow: Defining System Requirements: based on the platform requirements (D12.1) and platform specification (D13.1) a list of hardware requirements (considering each vehicle) will be provided. Physical Inspection: this point covers: o The quality of constructions resistance and robustnesso Physical design -practicality and sizeo Physical construction no sharp edges and system fito Accessibility -Toolless access and easily replaceableo Power -quality and easy Page 35

36 Testing via Software: It is the last process used to stress systems before putting them in the vehicle. It is used to find faulty hardware. Hardware-In-the- Loop (HIL) simulations for a variety of scenarios can be used. This technique allows minimizing risks and testing the specified requirements in each scenario. The manufacturer has the initial and primary responsibility for ensuring that these and other electronics systems in the vehicle work as intended, do not interfere with the safe performance of other systems, and can be used in a safe manner by the driver. The hardware architecture is made up by sensors, calculators, CPUs and communication buses that have to be tested individually then connected gradually. External conditions have to also be considered in the hardware testing process. It is very important to test the quality of sensor information. For example, testing visual interfaces of ADAS in real situation and different visibility conditions: daylight and darkness, fog and sunshine, cold or hot, among others Page 36

37 3. Software architecture As for hardware architecture, task identifies the characteristics and constraints that the software architecture has to fulfill to accept an application based on modules developed inside the DESERVE platform (Figure 15). AUTOSAR standards will be considered, but will not be treated as a pre-requirement. Figure 15: DESERVE platform architecture The key architecture challenges are: AUTOSAR Standards Architecture for the full platform system including performance accelerators Page 37

38 Request for high SW re-usability / testability including re-use of older generation software blocks Fast time to market High-optimized library for optimal performance Automatic code generation Standard Compiler/Tool chain Finally, hardware tool software support for realtime debugging, high speed parallel sensor data capture for validation and on-system debugging is required Specification of the software architecture The hardware architecture, as defined and described in chapter 2.1, needs an accompanying software framework to work properly. A common, all-embracing tool chain that spans over all the three development levels, would be ideal, but is not at all realizable (even for the PC-based development level two incompatible operating systems, namely Windows and Linux, exist). In fact, the hardware architecture typically dictates the software structure and design on large-scale. What is needed is a software tool that operates in each of the three development levels individually with the capability to conduct at least some general SW verification and validation tasks. For the PC-based level1 development, there exist already open source standardization initiatives like OpenCL or OpenCV that can be used in the respective software tool chains. In Figure 16 functions of already existing software blocks in the standardized toolbox for Computer Vision (CV) are shown. The availability of these same blocks, with the same API, on diverse runtime hosts, allows the functional elements to move between the hosts. Thus, the standard APIs and availability of these blocks as resources is a key part of the software architecture Page 38

39 Figure 16: Open CV functions Another important aspect for the software design is the real time capability. Real time operation system (RTOS) functionality is mandatory for the final target platforms of development level 3. For the PC-based development level 1 the ability for RTOS is not given for Windows -related systems and only to a limited extent for embedded Linux operation systems. For the intermediate level 2 (embedded controller development phase) real-time operation can be guaranteed with the respective RTOS applied. The next software requirement to be addressed is the bypassing functionality that requires specific interfaces to bring the hardware accelerators in the loop. The hardware in the loop (HIL) concept for the DESERVE development platform is thought to stretch Page 39

40 over all the three development levels, i.e. the PC-based SW-tool shall be capable to do HIL-bypassing with the embedded controllers of level 2 and the HW accelerators of level 3. A fundamental prerequisite to make this approach working is that the SW of all the three levels respects the OSI model layer architecture that regulates communication by specific protocols and instances. Figure 17: OSI seven layer model for computer network communication In Figure 17 the OSI model for computer networks is sketched for reference purposes. The DESERVE platform may have less or slightly modified layers but should follow in principle the general concept of the OSI model. The final SW architecture requirement Page 40

41 can be also drawn out of Figure 17. The application layer with dedicated API functions is essential for program abstraction and separation from the physical hardware peculiarities. In practice, most often an API is a library that includes specifications for routines, data structures, object classes, and variables. An API specification can take many forms, including an International Standard such as POSIX (a family of standards specified for maintaining compatibility between operating systems), vendor documentation (such as the Microsoft Windows API) or the libraries of a programming language (e.g., Standard Template Library in C++, Java API, OpenCL or OpenCV). With API programming techniques it is even possible to integrate hardware accelerators into a high-level runtime environment of a computer. This corresponds then to PIL (processor in the loop) acceleration techniques that may be needed to speed-up the PCbased level 1 development stage of the DESERVE platform. The compliance with AUTOSAR software architecture and principles should be maintained when designing the respective DESERVE platform modules as far as needed. For automotive applications AUTOSAR is anyway self-evident Application Software Modules On the base of AUTOSAR standard, the general software architecture can be represented in three main layers: Low Level - Basic Software: this level abstracts from the HW, provides basic and complex driver and services for high level (i.e. Memory, I/O). Middle Level Virtual Function Bus and Runtime Infrastructure High Level Application Software Components The AUTOSAR standard introduces two architectural concepts (respects to other embedded software architectures) that facilitate infrastructure independent software development. Namely, these are the Virtual Function Bus (VFB) and the Runtime Infrastructure (RTE) that are closely related to each other [9] Page 41

42 In order to realize this degree of flexibility against the underlying infrastructure, the AUTOSAR software architecture follows several abstraction principles. In general, any piece of software within an AUTOSAR infrastructure can be seen as an independent component while each AUTOSAR application is a set of inter-connected AUTOSAR components. Further, the different layers of abstraction allow the application designer to disregard several aspects of the physical system on which the application will later be deployed on, like: - Type of micro controller - Type of ECU hardware - Physical location of interconnected components - Networking technology / buses - Instantiation of components / Number of instances Figure 18: Overview on the principles of virtual interaction using the AUTOSAR The middle level, VFB, provides generic communication services that can be consumed by any existing AUTOSAR software component. Although any of these services are virtual. They will in a later development phase be mapped to actual implemented methods, that are specific for the underlying hardware infrastructure. The RTE (runtime Page 42

43 environment) provides an actual representation of the virtual concepts of the VFB for one specific ECU. An AUTOSAR software component in general is the core of any AUTOSAR application. It is built as a hierarchical composition of atomic software components. The AUTOSAR software component can be divided in Application Software Component and AUTOSAR Interface. All these concepts are strictly related to software implementation on embedded system. Instead, DESERVE must cover all the development chain including off-line simulation and prototyping on high-level development platform. So it is important for DESERVE to preserve (and build up during the prototyping phase of the applications) the AUTOSAR modularity concept. Consequently, DESERVE focuses on the development of modular Application Software Components. The software architecture to be addressed by the DESERVE development framework has been split into three platforms: Perception, Application and Information Warning Intervention (IWI). The baseline for DESERVE is represented by the results of past and on-going research projects, and in particular of interactive addressing the development of a common perception platform (Figure 19). In this architecture the Perception Platform processes the data received from the sensors that are available on the ego vehicle and sends them to the Application Platform in order to develop control functions and to decide the actuation strategies. Finally, the output is sent to the IWI Platform informing the driver in case of warning conditions and activating the systems related to the longitudinal and/or lateral dynamics. The architecture is suitable for the development and simulation of several groups of DAS functions as identified in [6].For each Platform the complete list of software modules has been defined in order to cover all the 33 DAS functions described in D1.1.1 deliverable report [6]. The software specifications have been defined only for the modules to be developed and integrated in the target applications (demo vehicle/motorcycle, test bench, lab simulators) Page 43

44 Figure 19: DESERVE Platform splitting The software specifications of each module have been defined using a common template and verifying the correspondence (number and data type of parameters) between the input and output of possible linked modules. The report [8] is the first release of software specifications to start modules development. During software development in WP3 and WP4, a refinement of software modules parameter will be possible. The table in the Annex A summarizes the defined modules Concepts for client-server access As introduced in chapter 3 of the DESERVE deliverable D2.1.3 [15], the external bypass method is an established and well recognized approach to developing and optimizing ECU software functions. The original ECU performs all the software functions that do not need to be changed, while new functions, or ones undergoing modification, are computed Page 44

45 externally on a rapid prototyping system. The input and output variables of the bypass functions are exchanged with the ECU via dedicated bypass interfaces. Computation of each bypass function on the prototyping system is usually triggered by the ECU, so that the two systems run synchronously. More and more ECU functions require access to dedicated ECU services, e.g. to read or write entries in the diagnostic error memory, the Non-Volatile Memory (NVRAM) or to query the associated status. This kind of access is typically implemented in terms of a client-server interface which defines a set of operations that can be invoked by means of associated ECU service function calls. When it comes to developing higher level ECU application functions on a prototyping system there is the general need to access the above mentioned service functions on the ECU (see Figure 20) Figure 20: External bypassing and client-server communication As a rule, bypass implementations in the ECU require modifications to the ECU code. Typically, a specific bypass service and calls to the associated service function, also known as bypass hooks, are inserted into the existing ECU code for this. The main job of these bypass service calls is to make the input variables X of each new bypass function Y =f (X ) available to the prototyping system, to trigger the function calculation, and Page 45

46 finally to feed the output variables Y of the function into the ECU s code processing sequence. The bypass service contains an address table and data buffer in the ECU RAM which allows a flexible definition of the ECU variables to be read and written by the individual service calls without having to recompile the ECU code for this (see Service call #1 and Service call #2 in Figure 21). Figure 21: Service based bypassing extended by a concept for client-server access The concept for client-server access is based on the bypass service described above. This service is extended by additional tables which contain lists of ECU functions (memory addresses of the associated functions and call types) that can be invoked from the prototyping system. The argument call types refers to different function call methods in the binary code, for example methods compliant with EABI standard conventions for data types, register usage, stack frame organization and function parameter passing [16]. In Page 46

47 addition, the extended bypass service contains buffers for function arguments and function results. A dedicated block in the Simulink model calculated on the prototyping system allows an ECU function to be selected and to be associated with a bypass service call on the ECU. The ECU functions available for client-server access on the ECU are defined in the matching ECU variable description file [17]. This block feeds the function argument values u into the respective fcn argument buffer, the service call on the ECU then invokes the matching server function f server () based on the related argument values from the fcn argument buffer and sends the return values a back to the prototyping system via the fcn result buffer and the bypass interface. For this, the bypass service functionality and the associated processing sequence are extended as given below: 1. New: Execute an ECU internal function call 2. Read data from the prototyping system 3. Trigger an interrupt on the prototyping system 4. Write data to the prototyping system 5. New: Execute an ECU internal function call Depending on the configuration done in the Simulink model, no step, one, multiple or all steps of this processing sequence can be executed by a call to the bypass service at once Multi-task option to permit adding and removing of functionalities The modularity is one the most important directive in the design of a global architecture, their functions and modules for embedded systems. Different multi-tasks (called processes) can be executed by sharing common processing resources in the same CPU. In this line, multi-thread languages as C++ are used by different developers around the world Page 47

48 The software environments used in the DESERVE platforms (e.g.: ADTF and RTMaps) are able to transfer functions already programmed in C and C++. These tools are multi-sensory software, designed for fast and robust implementation in multitask systems [4]. They use functional blocks (called components) for data flowing between different types of modules: video, audio, byte streams, CAN frames, among others. This multi-threaded architecture allows the use of multiple asynchronous sensors within the same application (see RTMaps and ADTF sections in [4]). Moreover, they take advantage of multi-processor architecture for more computing power. Based on the Development Platform Requirements [18], there are three main stages in the control architecture: perception, application and IWI platform. The goal of the DESERVE approach is to add different functions (Multi-task) in the same platform Hardware optimized software functionalities Advanced Driver Assistance Systems (ADAS) are systems to help the driver in the driving task. When designed with a safe Human Machine Interface (HMI) they will increase vehicle safety and more generally road safety. Examples for such systems are: Adaptive cruise control (ACC) Lane departure warning system Lane change assistance Collision avoidance system Traffic sign recognition Common to all those applications is that they are heavily using DSP algorithms primarily for image and radar processing. As a general rule, most of the processor resources will be consumed by the algorithmic part of the application. Availability of an AURIX (see footnote 1 on page 29) DSP optimized algorithm contributes to high performance execution and significant reduction of application development time Page 48

49 Motivation for the DSP library To achieve performance in code execution at a reasonable price in terms of power consumption and chip area, utilization of compiler optimized code is not enough. An alternative is hand optimizing the C code in assembly but this will cost a lot of effort in terms of time and will make the code architecture centric. The best compromise is to propose a DSP library with standard signal processing capabilities and a standardized (or well defined) API for further enhancements and code portability Function naming convention Function naming convention listed in the table below shall be applied: The function name consists of prefix (e.g. Ifx for Infineon Technologies) providing information on the owner of the function, the function itself (e.g. fft for Fast Fourier Transform) and the data format (e.g. RealF32 for real numbers float single precision). Functions will be assigned to function groups, e.g. mtx (matrix functions) or img (image processing functions) Page 49

50 Calling convention Most of the implemented functions have associated instance structure used for transferring of function parameters. Following example explains the required definitions and initializations before the function can be used. Used functions: void Ifx_mtxSvdRealF32 (struct Ifx_mtxSvdRealF32State *); //defined in dsplib.h Associated Structure declaration, also defined in dsplib.h: struct Ifx_mtxSvdRealF32State { enum Ifx_mode mode; float32 * a; float32 * w; float32 * v; uint32 m; uint32 n; }; Each structure has mode parameters defining the optimization level of the function. Additional parameters are specific for each function. Before a function can be used, first variable of type Ifx_mtxSvdRealF32State needs to be defined and the structure members require to be initialized Target Function list Following functions are targeted to be implemented in the DSP library and optimized based on TriCore hardware Page 50

51 Page 51

52 Page 52

53 3.6. Use of ADTF together with FPGA based development platform The use of ADTF together with the FPGA-based development platform allows to perform the same basic or complex signal processing operations purely in software (implemented as ADTF-Filters), purely in hardware (implemented on the FPGA), or in a combined software/hardware environment. This combination provides the required flexibility in the development process to evaluate new ADAS algorithms. An exemplary development process for an ADAS application example is described in the following paragraphs. The application example performs traffic sign detection in video camera images following an algorithm from [5]. The single processing steps are depicted in Figure 22. Figure 22: Overview of an exemplary sign detection algorithm Page 53