INCHRON Real-time Congress

Transkript

1 Integration of previously independent control units and functions challenges of a collaboration project INCHRON Real-time Congress I/EE-64, Bernhard Augustin

2 Content: 1. Starting point: Motivation for integration of control units 2. Challenges: New roles and tasks for OEM and Tier1 Interaction of functions from the perspective of event chain analysis - A practice-based report 4. Outlook 2 I/EE-64, Bernhard Augustin, June 2010

3 Content: 1. Starting point: Motivation for integration of control units 2. Challenges: New roles and tasks for OEM and Tier1 Interaction of functions from the perspective of event chain analysis - A practice-based report 4. Outlook 3 I/EE-64, Bernhard Augustin, June 2010

4 1. Starting point: Motivation for integration of control units The number of functions and control units in the vehicle is constantly increasing Costs "Simple" CAN components have "minimal infrastructure" (uc, voltage regulator,...) Production time Logistics costs Technology High integration in semiconductor ASICs Concurrent performance increase in ucs Build space "Simple" CAN components minmal size 6x6x2 cm³ Installation space is tight Energy Operating current ~ 60mA Weight of components ~ 80g Weight of clips and cabling 4 I/EE-64, Bernhard Augustin, June 2010

5 1. Starting point: Motivation for integration of control units Criteria for integration: Commercial criteria Installation rates: are optional equipments integrated in series control units, are there overhead costs? In which domains do the functions belong are there synergies regarding networking and complexity? Are functions alternately active are there resource-sharing synergies? Are there synergies in the organisational structure: At the OEM: Synergies vs. different processes in the departments concerned? At the supplier: do the parties involved appear as competitors? What are the safety requirements and specifications for the development process (A-SIL-classification) 5 I/EE-64, Bernhard Augustin, June 2010

6 1. Starting point: Motivation for integration of control units Specific example: Integration in body computer Tier1 supplier is integrated into a control unit Tier1 supplier is replaced by software developed in-house 3 control units are merged into 1 SWC_1 SWC_2 6 I/EE-64, Bernhard Augustin, June 2010

7 1. Starting point: Motivation for integration of control units 2. Challenges: New roles and tasks for OEM and Tier1 Interaction of functions from the perspective of event chain analysis - A practice-based report 4. Outlook 7 I/EE-64, Bernhard Augustin, June 2010

8 Gain: Benefits Risk: Risks Function 1, which portrays pure software functionality Function 2, which benefits from semiconductor integration Sufficient synergies can be realised "Hard criteria fully met (costs, weight, etc.) Components from different domains are integrated Suppliers appear as competitors Project goes beyond organisational limits at the OEM Clear responsibility relationship (development and series) no longer a given Integration leads to new development partnerships and constellations Integration requires new development partnerships and constellations New requirements for the development process (OEM and supplier) Methodical support Abstraction of the IPs between the suppliers Description of the relevant system-determining features: Formulation of real-time requirements Proof of adherence to these properties (responsibility!) 8 I/EE-64, Bernhard Augustin, June 2010

9 Gain: Conventional development process Risk: Integration and development process Tier1 develops and delivers the control unit as a complete system Tier1 has in-depth expertise about the complete system Tier1 is responsible for the full control unit verification OEM verifies the vehicle integration Tier1 has other "Tier1" suppliers, who are not sub-contractors (competitive situation!) OEM in-house development is integrated Tier1 can no longer fully verify the entire control unit (external functions are not free from repercussions) OEM becomes a "2nd integrator role Integration leads to new development partnerships and constellations Integration leads to new distributions of responsibilities OEM defines architecture requirements for the host control unit OEM understands and conveys the interface requirements of the respective function Supplier describes the previously implicitly available features as a requirement Integration tests by OEM move from the vehicle level to the control unit level Integration tests must also be carried out at the OEM (only OEM has access and understanding of all functions) 9 I/EE-64, Bernhard Augustin, June 2010

10 Bootloader/Flasher EcuStateM ComM DEH Collaborative project: Control unit integration 2. Challenges: New roles and tasks for OEM and Tier1 Co-design of the control unit architecture by the OEM! SWC Supplier Zulieferer BCM Application Layer SWC Supplier_2 Zulieferer_2 SWC In-House Eigenentwicklung Developed Specifics: AUTOSAR Runtime Environment (RTE) Complex device drivers Specific SPI drivers System Services UDS SDS Communication Services LIN COM SM Generic NM Interface CDD KS IPDUM PDU Router CAN TP CAN SM CAN NM BAP XCP LIN Interface Communication Hardware Abstraction CAN Interface SPI CDDx Communication Drivers LIN Driver CAN Driver Microcontroller 10 I/EE-64, Bernhard Augustin, June 2010

11 1. Starting point: Motivation for integration of control units 2. Challenges: New roles and tasks for OEM and Tier1 Interaction of functions from the perspective of event chain analysis - A practice-based report 4. Outlook 11 I/EE-64, Bernhard Augustin, June 2010

12 Analysis of previous, also implicitly available system properties => requirements derived for the new overall system Consideration of hardware dependencies or hardware restrictions in the practical implementation: which resources are available (e.g. number of available DMA channels) Requirements for real-time capability: Requirement analysis of all project partners Requirements for the task-model (activation rate) Requirements for jitters, latencies Data processing: Requirements for data consistency, consequences of multiple processing of data or data loss 12 I/EE-64, Bernhard Augustin, June 2010

13 Overview of criteria applied in the project (for every SWC) Echtzeitkriterium Anforderung Bewertung Echtzeitkriterium Anforderung Bewertung Antwortzeiten Antwortzeiten Zeitkritische Wirkketten Antwortzeiten Zeitkritische Start-to-start Wirkketten Jitter Zeitkritische Wirkketten Gewährleistung Start-to-start Datenkonsistenz Jitter Gewährleistung Datenkonsistenz Start-to-start Interrupts Jitter Die Funktionen müssen vor erneutem Einsprung kann noch nicht bewertet werden: beendet sein (alle Tasks). Die Funktionen müssen vor erneutem Einsprung Funktionslaufzeiten sind nicht bekannt kann noch nicht bewertet werden: beendet n/a sein. Funktionslaufzeiten sind nicht bekannt Echtzeitkriterium Anforderung Bewertung Die Berechnung Der Start-to-Start-Jitter der Kommandodaten ±2ms des und die Die Funktionen Übertragung Funktionseinsprungs müssen des vor SPI-Frames erneutem in müssen der Einsprung 5ms-Task vor erneutem muss kann noch ist bei nicht ist der bei bewertet Platzierung der Platzierung werden: der Funktionen der Funktionen zu zu beendet Einsprung sein berücksichtigen eingehalten (10ms-Task die Bewertungsfunktion werden. und 5ms-Task). abgeschlossen Funktionslaufzeiten berücksichtigen sind nicht bekannt Jede zweite sein. 5ms-Task muss nach der 10ms-Task nicht gewährleistet in der geplanten Task- Während der Funktionslaufzeit muss die ausgeführt Der werden Start-to-Start-Jitter (nur Variante ist gewährleistet: Signale werden in einen internen Konsistenz der gelesenen ±1ms A). des Konfiguration Signale gewährleistet ist bei Puffer der Platzierung kopiert der Funktionen zu In der 10ms-Task Funktionseinsprungs werden. bereitgestellte in der CAN-Signale 10ms-Task muss berücksichtigen müssen eingehalten zeitnah auf werden. dem CAN-Bus gesendet nicht gewährleistet in der geplanten Konfiguration Während des Kopiervorgangs eines CAN-Signals werden. Wenn Die maximale vom über CAN-Puffer einen Latenzzeit Interaction ist in den Layer noch nicht lokalen Makro-Aufruf der 10ms-Task (CAN Rx und Tx am Anfang) Puffer darf das nicht gewährleistet: ist gewährleistet: beim IRQs Zugriff werden auf den gesperrt bekannt. Interaction mehrere CAN-Signale nicht gelesen geändert werden, werden. muss Layer über Makros wird immer das neueste Der Start-to-Start-Jitter sichergestellt sein, ±2ms dass des diese Signale atomar d.h. Während kritischer Bereiche in Tasks müssen empfangene CAN-Signal zurückgegeben konsistent geliefert werden. ist bei der Platzierung der Funktionen Funktionseinsprungs in der 10ms-Task muss ist gewährleistet: IRQs werden gesperrt IRQs gesperrt werden. berücksichtigen eingehalten Wenn werden. CAN-Signale mehrfach unverändert Der Start-to-Start-Jitter verarbeitet werden ±1ms sollen, des muss deren Konsistenz wird durch die Valeo-Implementierung sichergestellt während der Funktionslaufzeit gewährleistet ist bei der Platzierung der Funktionen zu Funktionseinsprungs in der 5ms-Task (nur Variante werden. berücksichtigen A) muss eingehalten werden. Während Während der Lesevorgänge der Abarbeitung muss der die Funktionen darf keine nicht gewährleistet: kann noch nicht beim bewertet Zugriff auf werden: Interaction Gewährleistung Lösung ist nicht Datenkonsistenz Unterbrechung im Interaction durch Aufrufe Layer an gewährleistet der APS- Layer über bekannt Makros wird immer das neueste Datenkonsistenz werden. Schnittstelle erfolgen. empfangene CAN-Signal zurückgegeben Interrupts Während n/a der Funktionslaufzeit muss die Konsistenz gewährleistet über Wrapper-Funktionen der gelesenen Signale gewährleistet werden. IRQs dürfen nicht verloren gehen (nur Variante- kann noch nicht bewertet werden: IRQ-Pufferung im Interrupts Variante). Controller nicht bekannt Während der SPI-Kommunikation müssen IRQs IRQs müssen gesperrt werden gesperrt werden. 13 I/EE-64, Bernhard Augustin, June 2010

14 Specific integration task: Several functional components (runnables) from different ECUs are merged onto one ECU SWC_in-house development: 5ms task with 1 runnable and one 10ms task with 1 runnable Data is exchanged between the tasks with defined maximum processing latency (timing requirement) SWC_supplier_BCM: inc. 10ms task with 1 runnable Impact: Runnable of SWC_in-house development is integrated into the 10ms task of the SWC_supplier_BCM Timing requirements influenced by longer operating period and thereby infringement! 14 I/EE-64, Bernhard Augustin, June 2010

15 Prior to integration: The runnables run on different resources and do not influence each other 15 I/EE-64, Bernhard Augustin, June 2010

16 Prior to integration: Increased function density => longer task run time => poss. infringement of timing requirements. 16 I/EE-64, Bernhard Augustin, June 2010

17 Example 1: Impact of jitter behaviour In the stand-alone system, a 10ms task can always be processed so that during this time span a 5ms task can always be computed exactly twice In an integrated overall system this cannot be guaranteed 10ms-Task: netto Ausführungszeit 2ms, Start-to-Start-Jitter ±2ms 5ms-Task: netto Ausführungszeit 100µs, Start-to-Start Jitter ±1ms Drei 5ms-Tasks mit gleichen Sollwerten Repeated processing of data Solution: Change of algorithms Impact on the customer function 17 I/EE-64, Bernhard Augustin, June 2010

18 Example 2: Distribution of jitter behaviour A drift of the start-to-start jitter > task cycle time leads to further processing of aged data (e.g. late updating of data) Control can show jumps in the signal sequence, error states in the system Solution: Synchronisation through fixed time process flow of dependent control via CAN Bandwidth Start-to-Start Jitter Entry Appl. N to entry Appl. N: from >7ms to <13ms 18 I/EE-64, Bernhard Augustin, June 2010

19 Description of time-critical event chains (upstream/downstream relationships) Definition and assessment of real-time requirements Echtzeitkriterium Anforderung Bewertung Echtzeitkriterium Anforderung Bewertung Die Funktionen müssen vor erneutem Einsprung kann noch nicht bewertet werden: Echtzeitkriterium Antwortzeiten beendet Anforderung sein (alle Tasks). Bewertung Funktionslaufzeiten sind nicht bekannt Die Funktionen müssen vor erneutem Einsprung kann noch nicht bewertet werden: Antwortzeiten Zeitkritische Wirkketten beendet n/a sein. Funktionslaufzeiten sind nicht bekannt Die Funktionen müssen vor erneutem Einsprung kann noch nicht bewertet werden: Antwortzeiten beendet Die sein Berechnung Der (10ms-Task Start-to-Start-Jitter der und Kommandodaten 5ms-Task). ±2ms des und die Funktionslaufzeiten sind nicht bekannt ist bei der Platzierung der Funktionen zu Start-to-start Jitter Übertragung Funktionseinsprungs des SPI-Frames in müssen der 5ms-Task vor erneutem muss ist bei der Platzierung der Funktionen zu Zeitkritische Wirkketten Jede zweite 5ms-Task muss nach der 10ms-Task nicht gewährleistet berücksichtigen in der geplanten Task- Zeitkritische Wirkketten Einsprung eingehalten die Bewertungsfunktion werden. abgeschlossen berücksichtigen ausgeführt werden (nur Variante A). Konfiguration sein. Während der Funktionslaufzeit muss die Gewährleistung In der 10ms-Task bereitgestellte CAN-Signale Der Start-to-Start-Jitter ist gewährleistet: Signale werden in einen internen Konsistenz der gelesenen ±1ms des Signale gewährleistet Datenkonsistenz müssen zeitnah auf dem CAN-Bus gesendet nicht gewährleistet bei Puffer der Platzierung in kopiert der geplanten der Funktionen Konfiguration zu Start-to-start Jitter Funktionseinsprungs werden. in der 10ms-Task muss werden. Die maximale Latenzzeit ist noch nicht der 10ms-Task berücksichtigen (CAN Rx und Tx am Anfang) eingehalten werden. bekannt. Während des Kopiervorgangs eines CAN-Signals Wenn vom über CAN-Puffer einen Interaction in den Layer lokalen Makro-Aufruf Der Start-to-Start-Jitter ±2ms des Puffer darf das nicht gewährleistet: ist gewährleistet: beim IRQs Zugriff werden auf den gesperrt Interaction Gewährleistung mehrere CAN-Signale nicht gelesen geändert werden, werden. muss ist bei der Platzierung der Funktionen zu Start-to-start Jitter Funktionseinsprungs in der 10ms-Task muss Layer über Makros wird immer das neueste Datenkonsistenz sichergestellt sein, dass diese Signale atomar d.h. berücksichtigen eingehalten werden. Während kritischer Bereiche in Tasks müssen empfangene CAN-Signal zurückgegeben Interrupts konsistent geliefert werden. ist gewährleistet: IRQs werden gesperrt Der Start-to-Start-Jitter IRQs gesperrt ±1ms werden. des Wenn CAN-Signale mehrfach unverändert ist bei der Platzierung der Funktionen zu Funktionseinsprungs in der 5ms-Task (nur Variante verarbeitet werden sollen, muss deren Konsistenz berücksichtigen A) muss eingehalten werden. wird durch die Valeo-Implementierung sichergestellt während der Funktionslaufzeit gewährleistet Während werden. der Lesevorgänge muss die nicht gewährleistet: beim Zugriff auf den Interaction Gewährleistung Datenkonsistenz im Interaction Layer gewährleistet Layer über Makros wird immer das neueste Datenkonsistenz Während der Abarbeitung der Funktionen darf keine werden. empfangene kann noch CAN-Signal nicht bewertet zurückgegeben werden: Lösung ist nicht Unterbrechung durch Aufrufe an der APS- bekannt Während Schnittstelle der Funktionslaufzeit erfolgen. muss die Konsistenz gewährleistet über Wrapper-Funktionen der gelesenen Signale gewährleistet werden. Interrupts n/a IRQs dürfen nicht verloren gehen (nur Variante- kann noch nicht bewertet werden: IRQ-Pufferung im Interrupts Variante). Controller nicht bekannt Während der SPI-Kommunikation müssen IRQs IRQs müssen gesperrt werden gesperrt werden. 19 I/EE-64, Bernhard Augustin, June 2010

20 Experience gained from project: In-depth analysis of functional requirements helps to identify simple measures to bring about a solution Identification of actual requirements is hindered by A lack of understanding between the project partners with regards to functional requirements Expertise protection can often not be circumvented (competitive situation!) Development supported through methodical abstraction and moderation by INCHRON. 20 I/EE-64, Bernhard Augustin, June 2010

21 1. Starting point: Motivation for integration of control units 2. Challenges: New roles and tasks for OEM and Tier1 Interaction of functions from the perspective of causal analysis - A practice-based report 4. Outlook 21 I/EE-64, Bernhard Augustin, June 2010

22 4. Outlook Description of event chains in complex systems is required at an early stage Integral part of the design phase: Feasibility analysis Important criteria in the bid phase: Competence of the supplier Clear specification of the roles and responsibilities Who is responsible for the real-time capability Who delivers which contribution to the overall system analysis How is real-time capability continuously verified? Model-based approach from project start Ongoing verification of current task-models during development "Problem only identified during project" "next time systematically from the start" 22 I/EE-64, Bernhard Augustin, June 2010

23 4. Outlook Real-time requirements and methods Echtzeitkriterium Anforderung Bewertung Antwortzeiten Die Funktionen müssen vor erneutem Einsprung beendet sein (10ms-Task und 5ms-Task). kann noch nicht bewertet werden: Funktionslaufzeiten sind nicht bekannt Zeitkritische Wirkketten Jede zweite 5ms-Task muss nach der 10ms-Task ausgeführt werden (nur Variante A). nicht gewährleistet in der geplanten Task- Konfiguration In der 10ms-Task bereitgestellte CAN-Signale müssen zeitnah auf dem CAN-Bus gesendet werden. Die maximale Latenzzeit ist noch nicht bekannt. nicht gewährleistet in der geplanten Konfiguration der 10ms-Task (CAN Rx und Tx am Anfang) Start-to-start Jitter Der Start-to-Start-Jitter ±2ms des Funktionseinsprungs in der 10ms-Task muss eingehalten werden. ist bei der Platzierung der Funktionen zu berücksichtigen Gewährleistung Datenkonsistenz Der Start-to-Start-Jitter ±1ms des Funktionseinsprungs in der 5ms-Task (nur Variante A) muss eingehalten werden. Während der Lesevorgänge muss die Datenkonsistenz im Interaction Layer gewährleistet werden. ist bei der Platzierung der Funktionen zu berücksichtigen nicht gewährleistet: beim Zugriff auf den Interaction Layer über Makros wird immer das neueste empfangene CAN-Signal zurückgegeben will become part of the specification Während der Funktionslaufzeit muss die Konsistenz der gelesenen Signale gewährleistet werden. gewährleistet über Wrapper-Funktionen Interrupts IRQs dürfen nicht verloren gehen (nur Variante- Variante). kann noch nicht bewertet werden: IRQ-Pufferung im Controller nicht bekannt Während der SPI-Kommunikation müssen IRQs gesperrt werden. IRQs müssen gesperrt werden 23 I/EE-64, Bernhard Augustin, June 2010

24 Bootloader/Flasher EcuStateM System Services ComM DEH Communication Services Communication Hardware Abstraction Communication Drivers CDD Collaborative project: Control unit integration 5. Review Competence: Method Moderation - Tools SWC In-housedevelopment SWC Supplier BCM SWC Zulieferer BCM Application Layer SWC Zulieferer_2 AUTOSAR Runtime Environment (RTE) SWC Eigenentwicklung SWC Supplier_2 UDS SDS COM LIN SM Generic NM Interface KS OEM skills PDU CAN Router SM IPDUM CAN TP LIN CAN Interface Interface LIN CAN Driver Driver CAN NM BAP XCP SPI CDDx Supplier skills Microcontroller 24 I/EE-64, Bernhard Augustin, June 2010