CAN Configuration Within Autosar
iCC 2006CAN in AutomationCAN configuration within AutosarDr.-Ing. R. Machauer, Bosch Engineering GmbHAUTOSAR (AUTomotive Open System ARchitecture) aims to standardize interfacesbetween software application functions and further between application functions andbasic software modules in ECUs (Electronic Control Unit). Independence fromunderlying hardware and this modular software design allows exchangeability ofsoftware functionalities amongst ECUs. The integration of functions from differentsuppliers is established through a virtual function bus. The mapping to a certainnetwork topology (or to ECUs) is carried out after that step. In this paper configurationof a CAN stack and related basic software modules in system architecturedevelopment according to AUTOSAR is shown.TheAUTOSARpartnershipwasestablished in summer 2003 [1]. Firstrelease of AUTOSAR specification waspublished in mid 2005. A second releasefollowed during the first quarter of 2006[2]. In chapter 2 a short technical overviewof the AUTOSAR concept and its layermodel is given. In chapter 3 the BasicSoftware(BSW)modulesofcommunication software(COM stack) andthe underlying layers are discussed indetail.1 IntroductionNowadays in automotive environment E/Esystems comprise of many ECUs, whichare connected via different bus systems(CAN, LIN, FlexRay, MOST, proprietaryserial lines, etc.). In luxury cars thenumber of ECUs may even reach 70. Theyare classified into several system domainslike powertrain domain, chassis domain,body domain, safety, infotainment, etc.Inter domain communication is establishedthrough gateways. The functional behaviorof an ECU is specified by the OriginalEquipment Manufacturer (OEM), andimplemented by the hardware supplier.Each ECU implements certain applicationfunctions, which interact in some way withother ECUs. It is a common approach, thatECU hardware manufacturers also supplyapplication software with their ECU. Withthis approach the system integrationmedium is more or less the bus systemthe ECU is connected to. With such alarge number of ECUs and interactingfunctions error detection within a system isa challenge for the system integrator. Thedriving forces for AUTOSAR are [1]: Exchangeability of functional modules(multiple suppliers) Manage increasing E/E complexityassociated with growth in functionalscope, which yields to improved qualityand reliability of E/E systems Higherflexibilityforproductmodification, upgrade and update Enable detection of errors in earlydesign phases2 AUTOSAR conceptThe AUTOSAR software architectureprovides new design choices to softwareengineersbuildingdistributed,communication software systems. A keyaspect of this architecture is a designabstraction called the AUTOSAR VirtualFunction Bus (VFB) (rf. Figure 1). VFBallows the design of software systemswithout reference to target hardware.Hence during the design process themapping to a specific hardware is shiftedto later phase. The VFB is the collection ofall communication mechanisms (plussome interfaces to the basic software) onan abstract level.An AUTOSAR system is build from of aset of software components (SW-Cs).Interaction among SW-Cs is accomplishedonly through statically defined ports. Eachport is assigned an interface type, definingthe “way” of communication. Twocommunication paradigms are provided forSW-C ports, called sender-receiver andclient-servercommunication;Sender06-12
iCC 2006receiverCAN in Automationprovidesmessagepassing,depicts the software layer architecture. AFigure 1: Virtual Function Bus [3]Figure 2: Software layer model [4]whereasclient-servercommunicationinvokes a service function call. VFB allowsan early (virtual) integration of SWCs assoon as the communication mechanismamongst SW-Cs are defined. TheAUTOSAR partnership specified a metamodel, described in the configurationlanguage XML. Hence XML configurationfiles can be used for the entire systemspecification. These XMLconfiguration filesare used as input for code generationtools, tools for creating object code or justas uniform specification exchange format.Additionally, development tools like busanalyzer, function modeling tools, etc. willsupport AUTOSAR exchange format inmidterm.The Run Time Environment (RTE) is therealization of the VFB for a specific ECU.The RTE realizes the communicationbetween SWCs within an ECU (intracommunication) and among differentECUs (inter-communication). SW-Cs withtheir ports and interfaces are mapped tocertain ECUs after the VFB system designstep. XML configuration files are used todescribe this mapping. After appropriatesystem configuration XML configurationfiles are fed to an RTE generatorproducing code (e.g. source code filesrte.c, rte.h, etc.) specific to an ECU. In thisway the RTE layer encapsulates the wholecommunication mechanism for SW-Cs byproviding a standardizes API to applicationfunctions and simultaneously beingindependent from actual underlyinghardware.color schema helps Figure 2: SoftwareLayer Model [4] in distinguishing differentlayers. The application layer resides ontop of the layer model. This is abstractedthrough the RTE from the underlyinghardware (including ECU). The RTE layeris generated completely by tools based onthe provided XML-schema. Developingsuch tools is not in the focus ofAUTOSAR, but they play a key role. BelowRTE all BSW-modules are divided intoseveral layers. Each layer abstracts itsadjacent underlying layers a certaindegree more from real hardware. Theservice layer (blue) comprises systemservices (e.g. Operating System (OS)),memory services (e.g. Non Volatile RAM(NVRAM)) and communication services(like bus communication). An example ofsuchabstractionwouldbethecommunication service layer, whichabstracts from communication hardware.The network system (LIN, CAN, FlexRay)is still not known. The hardwareabstraction layer, on the other side,supportsinterfaces,providingindependence from hardware driversoftwareand therefore fromrealmicrocontroller.Onboarddeviceinterfaces, memory hardware, I-O driversand communication hardware modules aredistinguished in the layer next to themicrocontroller.Thecommunicationhardware abstraction layer hides the usednetwork system. Through this module thenetwork system type is chosen. Forexample a CAN interface module is used,if signals shall be transferred on CAN.Apart from these hardware abstractionblocks two more (green) BSW modulesappear. Input/ Output (IO) hardwareabstraction layer hides controller specificproperties of input and output ports.Interfaces are provided to access data2.1 System layer modelA technical overview on AUTOSAR isgiven in [3]. This subsection focuses onthe architecture within an ECU. Figure 206-13
iCC 2006CAN in Automationfrom ECU inputs or to put data tohardware output ports with physicalvalues. The kinds of ports (Analog DigitalConverter (ADC), Pulse Width Modulated(PWM), or digital input/output) shall not beof relevance to upper layers. Therightmost side of Figure 2 shows anotherBSW module Complex Device Driver(CDD). CDD allows direct access of RTEto peripheral hardware. This module isused for very time critical applications,which can be speed up through directlyaccessing peripheral hardware. Furthersupplier can protect their IP within a CDD.the communication services layer apart3 COM stackThis section gives an elaborated overviewof the COM stack. For simplicity only theCOM stack for CAN communication issketched. Figure 3 gives more insight intothe layered architecture of COM relatedmodules. The service layer containsseveral modules. Subsection 3.1 gives anoverview of AUTOSAR COM, subsection3.2 gives details on PDUrouter, subsection3.3 gives an overview of CAN transportprotocol (CAN TP), subsection 3.4 andsubsection 3.5 summarize the task of CANInterface and of CAN Driver modules.Figure 3: Communication stack layermodel [4]fromAUTOSARCOM.Networkmanagement provides uniform services toget and set modes of networks nodes.3.2 PDU-Router3.1 COMThe PDU-Router [6] provides services forrouting I-PDUs between the followingmodules:AUTOSAR COM is based on the OSEKCOM specification [5]. The COM servicelayer provides a uniform interface to theCAN network. Protocol and messageproperties are hidden from the application.COM provides a microcontroller and ECUhardwareindependentinterfacetoapplication. COM transfers signals to andfrom the RTE. Signals are packed into andfrom I-PDUs. Dependent on the service tobe used, signals are directly passed totransport protocol modules or to the PDURouter. External signal exchange betweenSW-Cs on different ECUs are routedthrough RTE via COM to PDU-Router andthen to a bus system as configured duringsystem design. COM is able to work as asignal gateway, without inclusion of higherlayers. Attributes are attached to signals,which are managed and evaluated withinCOM. Network management is included in communication interface modules (e.g.LIN, CAN and FlexRay)Transport protocol modules (e.g. CANTP, FlexRay TP)AUTOSAR Diagnostic CommunicationManager(DCM)andTransportProtocol (TP) modules (e.g. CAN TP,FlexRay TP)AUTOSAR COM and communicationinterface modules (e.g. LIN, CAN orFlexRay) or I-PDU MultiplexerI-PDU Multiplexer and communicationinterface modules (e.g. LIN, CAN orFlexRay)The PDU router provides an API to theabove layers (e.g. COM) and an API for06-14
iCC 2006CAN in Automationmodules below the PDU router (e.g. CANinterface). PDUs are identified by staticPDU IDs. The routing operation of thePDU router is controlled by routing tables,which contain routing attributes for eachPDU, e.g.: PDU Id and destinationaddress. The PDU router does not modifyI-PDUs, it simply forwards the I-PDU to thedestination module. A detailed sketch ofthe PDU router structure is given in Figure4. The PDU-R module is split into twoparts: Detection of errors in segmentationsessionsThe main purpose of CAN TP is tosegment and reassemble CAN I-PDUslonger than eight bytes (data flow control).Two routing paths exist between CANinterface and PDU router engine (seeFigure 4). The PDU router determineswhether a transport protocol is to be usedor not. The PDU router can handledifferent communication protocols forCOM and DCM I-PDUs. COM I-PDUs aregenerally routed directly to CAN interface,whereas DCM I-PDUs are routed via CANTP, in a CAN network system. Diagnosticinformation [8, 9, 10] exceeds eight bytedata fields, which makes data flow controlnecessary.The PDU Routing tablesThe PDU Router engineThe PDU router engine performs routingactions according to the routing tables.Two translations can be distinguished: up(to higher layer) and down translation. Inorder to provide access to the DCM for theactivation of the bootloader, the PDUrouter engine provides a minimum routingcapability. Specific PDUs can hence berouted correctly to DCM in case theconfigurable PDU router tables arecorrupted (e.g. by a previous flashoperation).3.4 CAN interfaceThe CAN Hardware Interface providesuniform mechanisms to access a CAN buschannel regardless of its location (internal/external), i.e. upper layers do notdifferentiate, whether a CAN controller isconnected via an SPI bus or whether anon-chip CAN controller is used. CANInterface abstracts from the location ofCAN controllers (on-chip/on-board), theECU hardware layout and the number ofCAN drivers. The upper layer addressesCANchannelsratherthanCANcontrollers.3.5 CAN driverThe CAN Driver provides services forinitiating transmissions and callbackfunctions for notifying receive events,independent from the CAN controllerhardware.Figure 4: PDU router structure [6]3.3 CAN-TPCAN Transport Protocol (CAN-TP) islocated between PDU router and CANInterface (see Figure 3). CAN TP providesservices for [7]: 3.6 CAN transceiver driverThe CAN Transceiver driver controls theexternal CAN transceiver hardware. Itcontrols wake-up and sleep of the CANbus. It observes the bus line and providesphysicalnetworklayerdiagnosticinformation (short circuit, open line, etc.) tothe upper layers.Segmentation of data in transmitdirectionReassembling of data in receivedirectionControl of data flow06-15
iCC 2006CAN in Automationare written by the pport. A require port (rport) represents a read data elementoperation, as can be seen at the rightmostSW-C in Figure 5. Graphical tools will be(soon) available to configure SW-Cs bydrawing them as they are sketched inFigure 5. These tools support import andexport of XML code, in order to exchangeconfigurations with other tools. In the nextdevelopment phase SW-Cs are mapped tohardware (ECUs), which representsmapping to a certain system architecturedesign. Tools also assist in this step. Amanual way is, to map the SWCs bymeans of AUTOSAR XML code. After thisstep intra ECU and inter ECU signals aredistinguished for the first time. Forexample:If SensorInputProcessing is mapped toECU1 and the right SW-Cs MirrorAdjustManager, ActuatorOutputProcessing arelocatedonECU2,theportsPP Req MirrorandRP Req Mirrorexchange their data elements betweenECUs. Data elements between the portsPP cmd Mirror and RP cmd Mirror areintra ECU signals. In case no specialrouting is necessary, nothing is to be donefor intra-ECU signals. All intra ECU trafficof SWCs is managed by RTE. Inter ECUsignals are communicated to externaldevices. They are passed from RTE toCOM and vice versa. COM packs signalsinto I-PDUs, which contain one ore moresignals. Signals within a COM I-PDU mustoccupy contiguous bits. Signals in COMlayer need a reference to data elements ofSW-C ports. Data elements of SW-C portshas to be mapped to I-PDU signals.Through this mechanism data elementsfrom SW-C ports are linked to externalnetworks (a CAN network in this case).While transmitting the PDU-Router readsthe I-PDUs and routes them according tothe routing table to lower layers. In case ofreception PDU-R transfers I-PDUs withoutmodifications to upper layers.4 Example applicationIn this section the configuration andintegration process of a small mirror demoapplication is illustrated. First the ing,MirrorAdjustManager,ActuatorOutputProcessing. These SW-Cscommunicate with each other over portsand their assigned interfaces. Figure 5depicts the top level design. A small mirrorcontrolapplicationservesasademonstration. The example systemconsists of three SW-Cs. The left SW-C(SensorInputProcessing) reads in sensorinformation provided by the car driver viajoystick movements. The right SW-C(ActuatorOutputProcessing)sendssteering commands to actuators. TheMirroAdjustManager SW-C ing move commands. At thisstep sensor- and actuator componentdepends on logic signals, like: MoveX,MoveY, Stop, etc. Now ports, interfacesand data elements are defined. Table 1shows an extract of a software componentXML description. For simplicity a table isused instead of copying XMLcode. Table 1is related to the leftmost SW-C of Figure 5.The name of the atomic SW-C is definedin the first row. The component contains aproviding port (p-port) PP Req Mirror,which uses a sender-receiver (S/R)interface of type IF MirrorMoveXY. Thecommunicationtypesender-receiverinvolves transmission and reception ofsignals for atomic data elements. An S/Rinterface may contain multiple dataelements. Here DT Req MoveX andDT Req MoveY are two data entPrototypeSettingsCT SensorInputProcessingTypePP Req MirrorIF MirrorMoveXYDT Req MoveXDT Req MoveYTable1:SensorInputProcessingconfiguration parameters (extract)definedwithintheinterfaceIF MirrorMoveXY. These data elements06-16
iCC 2006CAN in Automationrouter selects to (or from) which networkinterface data is transferred. In case ofCAN the I-PDUs are put (or get) to theCAN Interface, which transfers them finallyto the CAN driver and from there to theCAN controller.6 Acronyms, abbreviationsFigure 5: SW-Cs of demo applicationADCBSWCAN-TPCDDDCM5 ConclusionThe AUTOSAR standard aims to achievestandardized interfaces between softwareapplication functions and from them tobasic software modules within . Software modules may beexchangeable due to a standardized APIto other modules or to applicationfunctions. In future automotive systemarchitectures the number of ECUs may bereduced, because of the ability to integrateSW-Cs on a virtual function bus in a quiteearly development phase. The increasingfunctional scope with the growingcomplexity may be kept feasible in futuresystems. The architectural concept ofAUTOSAR is based on a VFB. Per ECUthe VFB is instantiated as an RTE layer.RTEencapsulatesthewholecommunication infrastructure for SW-Cswhich build the application functions. BSWmodulesarestandardizedforconfiguration. Also BSW module APIs arepart of the AUTOSAR standardization,which yields exchangeable BSW modules(e.g. from different suppliers). Each layerabstracts gradually its underlying layerfrom hardware. Data elements of SW-Csare identified as internal or externalsignals when they are mapped to certainECUs according to a system networkarchitecture.Externalsignalsaretransferred through RTE to COM, wherethey are packed/ unpacked into/ from IPDUs. User data is put into (or get from)buffers of the PDU-router, which routesthe packed I-PDUs according to its routingtable. A default routing table exists fordiagnostic data exchange, which servesas backup in case a prior programsequence destroyed the routing table. TheNVRAMOEMPWMRTEOSTPVFBAnalog Digital ConverterBasic Soft wareCAN Transport ProtocolComplex Device DriverDiagnostic CommunicationManagerNon Volatile RAMOriginal EquipmentManufacturerPulse Width ModulatedRun Time EnvironmentOperating SystemTransport ProtocolVirtual Function BusReferences[1] H. Heinecke, K.-P. Schnelle, H. Fennel,J.Bortolazzi, L. Lundh, J. Leflour, J.-L.Mate, K.Nishikawa, and T. Scharnhorst, AUTomotiveOpen System ARchitecture -an industry-wideinitiative to manage the complexity ofemergingautomotivee/earchitectures.Convergence 2004, October 18-20 2004.[2] AUTOSAR.AUTOSARpartnershiphomepage: www.autosar.org.[3] AUTOSAR. Technical Overview, 2.0.0edition, March 2006.[4] AUTOSAR. Layered Software Architecture,2.0.0 edition, March 2006.[5] OSEK. OSEK/ VDX Communication, 3.0.1edition, January 2003.[6] AUTOSAR. Specification of PDUR, 2.0.0edition, April 2006.[7] AUTOSAR. Specification of CAN TransportLayer, 2.0.0 edition, April 2006.[8] ISO 15765-2 (2004-10-12), Road vehicles Diagnostic on Controller Area Networks(CAN) - Part2: Network layer services.[9] ISO 15765-3 (2004-10-06), Road vehicles Diagnostic on Controller Area Networks(CAN) - Part3: Implementation of DiagnosticServices.[10] ISO 15765-4 (2005-01-04), Road vehicles Diagnostic on Controller Area Networks(CAN) - Part4: Requirements for emissionrelated systems.06-17
release of AUTOSAR specification was published in mid 2005. A second release followed during the first quarter of 2006 [2]. In chapter 2 a short technical overview of the AUTOSAR concept and its layer model is given. In chapter 3 the Basic Software (BSW) modules of communication software(COM
AUTOSAR 3.x AUTOSAR 4.x AUTOSAR 3.x is used in serial production projects by: Audi / Volkswagen / Porsche Daimler Fiat / Chrysler Volvo Trucks (incl. Construction Machines) AUTOSAR 4.x is used in serial production projects by: BMW GM Toyota Volvo Cars AUTOSAR 4.x is generally announced by Ford PSA
Simon Fürst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich. 2 8 Nov. 2011 AUTOSAR and Functional Safety . Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
AUTOSAR User Group, i.e. the Artop User Group . –It is a group of AUTOSAR members and partners, i.e. users of AUTOSAR, with a special interest in AUTOSAR tools. –Was launched in October 2008 and the members currently are: –Continental –Geensys –Peugeot Citroën (PSA)–BMW Car IT –New members are welcome to join the User Group.
Both, Releases 2.0 and 2.1, are in use by several AUTOSAR members for series produc-tions. 2.2. Overview on AUTOSAR Phase II Three releases had been planned for AUTOSAR Phase II, providing a continuous improve-ment of the specifications and introducing new concepts. Release 3.0 was published early 2008 on the AUTOSAR web site [1]. It included a .
2 Introduction to AUTOSAR Simulink approach to AUTOSAR Overview of Modeling SWCs & Modeling Styles AUTOSAR Design Workflows Bottom Up, Top Down & Round Trip Advanced Topics –Top 5 Startup, Reset, and Shutdown Modeling Basic Software (BSW) Access J-MAAB Type B Architectu
Adaptive Environment - The AUTOSAR Adaptive environment for adaptive design AUTOSAR Builder is based on Eclipse and uses Artop. Artop is an open AUTOSAR tool environment that is available for free. It enables you to build your own tools and integrate from other tool vendors. For more details, see the AUTOSAR Builder Overview document. 1.
Configuration Management Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 888 Document Status published Part of AUTOSAR Standard Adaptive Platform Part of Standard Release R20-11 Document Change History Date Release Changed by Description 2020-11-30 R20-11 AUTOSAR Release Management Classic Plaftorm update .
AUTOSAR Methodology at BMW Page 2. OVERVIEW. AUTOSAR Versions and Roadmap Configuration Process until Generation 2015 Vision Generation 2021 and Current Status Generation 2018 Tool Architecture Tool Development ECU Configuration Flow AUTOSAR Tool Requirements for the Future
