Institutionen För Systemteknik - DiVA Portal
Institutionen för systemteknikDepartment of Electrical EngineeringExamensarbeteImplementation of CAN Communication Stack inAUTOSARExamensarbete utfört i Datorteknikvid Tekniska högskolan vid Linköpings universitetavJohan Alexandersson och Olle NordinLiTH-ISY-EX-ET–15/0440–SELinköping 2015Department of Electrical EngineeringLinköpings universitetSE-581 83 Linköping, SwedenLinköpings tekniska högskolaLinköpings universitet581 83 Linköping
Implementation of CAN Communication Stack inAUTOSARExamensarbete utfört i Datorteknikvid Tekniska högskolan vid Linköpings universitetavJohan Alexandersson och Olle rs Nilssonisy, Linköpings universitetSimon TegelidÅF ConsultingExaminator:Anders Nilssonisy, Linköpings universitetLinköping, 15 juni 2015
AbstractIn the automotive industry today, embedded systems have reached a level of complexity which is not maintainable with the traditional approach of designingautomotive embedded systems. For this purpose, many of the world’s leadingautomotive manufacturers have formed an alliance to apprehend this problem.This has resulted in AUTOSAR, an open standardized architecture for automotiveembedded systems, which strives for increased flexibility and safety regulations.This thesis will explore the possibilities of implementing a CAN Communicationstack using the AUTOSAR architecture and its corresponding methodology. As aresult of this thesis, a complete AUTOSAR CAN communication stack has beenimplemented, as well has a simulator application with the purpose of testing itsfunctionality.iii
AcknowledgmentsFirst and foremost, we would like to thank Simon Tegelid and Magnus Carlssonat ÅF, for endless support whenever needed. We would also like to thank Anders Nilsson at ISY for consistently being available with good advice. Additionalaccolades go out to friends and family.Linköping, June 2015Johan Alexandersson and Olle Nordinv
ContentsNotation1 Introduction1.1 The Company1.2 Background .1.3 Purpose . . . .1.4 Limitations . .1.5 Equipment . .ix.1112222 Theory2.1 AUTOSAR . . . . . . . . . . . . . . . .2.1.1 Layered Software Architecture2.1.2 Basic Software Layer . . . . . .2.1.3 BSW modules . . . . . . . . . .2.1.4 CAN Communication Stack . .2.1.5 Application Layer . . . . . . . .2.1.6 Runtime Environment . . . . .2.2 Controller Area Network . . . . . . . .2.2.1 Layers . . . . . . . . . . . . . .2.2.2 CAN Messages . . . . . . . . . .55678815171919193 Method3.1 AUTOSAR Methodology . . . . . . . . . . . . . . .3.1.1 BSW configuration . . . . . . . . . . . . . .3.1.2 Develop System Description . . . . . . . . .3.1.3 Design System . . . . . . . . . . . . . . . . .3.1.4 Develop Application Software Components3.1.5 Build ECU Software . . . . . . . . . . . . . .3.1.6 Modeling approach . . . . . . . . . . . . . .3.2 Development Tools . . . . . . . . . . . . . . . . . .3.2.1 Arctic Studio . . . . . . . . . . . . . . . . . .3.2.2 HALCoGen . . . . . . . . . . . . . . . . . .3.2.3 Code Composer Studio . . . . . . . . . . . .232324242425252526262627.vii.
viiiContents3.2.4 PyQtGraph . . . . . . . . . . . . . . . . . . .3.2.5 PyQt . . . . . . . . . . . . . . . . . . . . . .3.3 Project Method . . . . . . . . . . . . . . . . . . . . .3.3.1 Pre-Study . . . . . . . . . . . . . . . . . . .3.3.2 AUTOSAR Development . . . . . . . . . . .3.3.3 BSW Configuration . . . . . . . . . . . . . .3.3.4 Develop System Description . . . . . . . . .3.3.5 Develop Application Software Component .3.3.6 Design System . . . . . . . . . . . . . . . . .3.3.7 Build Ecu Software . . . . . . . . . . . . . .3.3.8 Simulator Application Development . . . .3.3.9 Testing . . . . . . . . . . . . . . . . . . . . .2727282830304042444647514 Results4.1 ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5353555 Discussion5.1 Analysis of the results5.2 Method . . . . . . . .5.3 Conclusions . . . . .5.3.1 Future work .7373747474.List of Figures76A Appendix A: Flowcharts81Bibliography85
ix
nACKAP IAU T OSARBSWCANCAN I fCCSCOMCRCDI ODLCECUECU CECU ME/EGI OGU IHWIDI DEI P DULP DUMCALMCUOSP DUP DU RRECRT ERT RSWSW CT ECAcknowledgementApplication Peripheral InterfaceAutomotive Open System ArchitectureBasic Software LayerControl Area NetworkCan InterfaceCode Composer StudioCommunicationCyclic Redundancy CheckDigital Input/OutputData Length CodeElectronic Control UnitECU ConfigurationECU ManagerElectrical/ElectronicGeneral-Purpose Input/OutputGraphical User InterfaceHardwareIdentifierIntegrated Development EnvironmentInternal Layer Protocol Data UnitData Link Layer Protocol Data UnitMicrocontroller Abstraction LayerMicrocontroller UnitOperating SystemProtocol Data UnitPDU RouterReceive Error CounterRuntime EnvironmentRemote Transmission RequestSoftwareSoftware ComponentTransmit Error Counter
1Introduction1.1The CompanyThis thesis will be conducted at ÅF Consulting in Linköping. ÅF Consultingis a Swedish consulting company with over 7000 employees all over the world[3]. The company covers many different areas including for example industry,infrastructure and technology. Our thesis will be carried out at ÅF’s technologysection.1.2BackgroundIn the automotive industry there has always been trouble with integrating software into different hardware components. In order to solve this problem, an international open source standard was developed in collaboration between manyof the world’s leading automotive companies. This standard was to be named AUTOSAR and its purpose is to improve the compatibility between different ECUs,regardless of hardware and manufacturer. At ÅF there has been a project with asmall electrical car model type Sinclair C5. This project has consisted of upgrading the hardware and developing some software for controlling the car. This hasbeen done in a traditional manner with no regard to the AUTOSAR specifications.One of the components of this vehicle is a control unit which controls the different units of the vehicle for example the motor driver. The control unit basicallyserves as a CAN-hub, sending and receiving messages to and from other ECUs inthe vehicle. This thesis will explore the possibilities of implementing this controlunit in a system based on the AUTOSAR system architecture.1
211.3IntroductionPurposeThe purpose with this thesis is to implement a platform for CAN-communicationusing the AUTOSAR system architecture, going through all software layers to agraphical interface on the PC. The main focus with this thesis will be the configuration of the BSW modules within AUTOSAR, as well as the implementationand modelling of the SWCs. The platform needs to be compatible with the CANnetwork of the Sinclair, which means it needs to be able to process 36 differenttypes of CAN IDs, and also to be able to send and receive messages with a datalength of 5 bytes. In specific, the following needs to be investigated: How to configure the Basic Software Modules in order to achieve CAN communication. How to create software components with the task of reading, interpreting,and writing CAN signals. How to set up the AUTOSAR Runtime Environment, which connects thesoftware components with the Basic Software Modules How to send and receive signals exceeding limits on internal signal lengths. How to create a GUI with the task of sending and receiving CAN signalsand displaying these signal values on a plot.1.4LimitationsThe following limitations are set for this project: The actual control unit software for the Sinclair will not be integrated inAUTOSAR software. Instead, a CAN communication stack will be implemented which will leave room for future integration of the control unitsoftware. Ethical aspects of any kind will not be discussed in this thesis.1.5EquipmentIn this thesis, the following equipment and software will be used: ArcCore Arctic Studio– An IDE based on Eclipse where AUTOSAR embedded applications aredeveloped. ArcCore Arctic Core– An embedded platform based on the AUTOSAR specification.
1.5Equipment Kvaser Leaf Light HS v2– USB Can Adapter Texas Instruments TMDX570LS20SMDK– A development kit for Cortex ARM-R MCUs3
2Theory2.1AUTOSARGiven the increased complexity in automotive embedded systems today, the automotive industry has seen a need of an open industry standard for automotiveelectronic architecture. This has resulted in many of the world-leading automotive companies forming a partnership, which goal is to establish this standard.The standard, as well as the partnership, is called AUTOSAR, which stands forAutomotive Open System Architecture. The partnership was founded in 2002,initially by BMW, Bosch, Continental, DamienChrysler, and Volkswagen, withSiemens joining the partnership shortly thereafter. [6]According to the AUTOSAR website, the motivation for establishing the standard are the following points: "Management of E/E complexity associated with growth in functional scope" "Flexibility for product modification, upgrade and update" "Scalability of solutions within and across product lines" "Improved quality and reliability of E/E systems"[5]The goals with AUTOSAR are the following: "Fulfillment of future vehicle requirements, such as, availability and safety, SWupgrades/ updates and maintainability" "Increased scalability and flexibility to integrate and transfer functions" "Higher penetration of "Commercial off the Shelf" SW and HW componentsacross product lines"5
62Theory "Improved containment of product and process complexity and risk" "Cost optimization of scalable systems"[5]2.1.1Layered Software ArchitectureSince one of the main goals of AUTOSAR is to provide flexibility, a layered software architecture has been conceived. It is mainly divided up in three layers,shown in Fig. 2.1 below.Figure 2.1: Layered Software Architecture2.1.1.1Basic Software LayerThe first layer, starting from the bottom, is called the Basic Software Layer (BSW).The purpose of this layer is to provide an hardware independent abstraction toother layers. This means that the BSW layer needs to interact with the microcontroller itself, making it hardware dependent. Due to this, the BSW layer needsto be implemented depending on what kind of hardware is used. The BSW layercontains standardized infrastructure for example the communication stack, thememory stack, diagnostic services, and the operating system. [7]2.1.1.2Runtime EnvironmentThe next layer in the architecture is the Runtime Environment, commonly abbreviated RTE. The purpose of this layer is to abstract the application layer fromthe BSW layer. In practice, this basically means that the RTE provides the Application Layer and the Basic Software Layer with a common interface, providinginteraction between the two layers. [7]
2.17AUTOSAR2.1.1.3Application LayerThe final layer is the Application Layer. This layer contains application moduleswhich are called Software Components (SWC). These contain software for thesystem which is completely hardware independent. This means for example thatan SWC of an ECU with one kind of hardware can interact with an SWC of anECU with another kind of hardware with great ease. [17]2.1.2Basic Software LayerThe Basic Software Layer is furtherly divided into sublayers, as shown in Fig. 2.2below. Explanations for layers not used in this thesis are excluded.Figure 2.2: Basic Software Layer2.1.2.1Microcontroller Abstraction LayerThe Microcontroller Abstraction Layer (MCAL) is the layer at the bottom of theBSW layer. The modules in this layer interact directly with the MCU. The purposeof this layer is to make layers above this layer hardware independent, as this layerprovides functions defined by the AUTOSAR specification. Given the fact thatthis layer interacts directly with the MCU, this layer is hardware dependent. [7]2.1.2.2ECU Abstraction LayerThe next layer in the BSW layer is called the ECU Abstraction Layer (ECUAL).This layer provides an interface of the drivers found in the MCAL layer to thelayers situated above the ECU Abstraction Layer. Drivers for external devicessuch as CAN transceivers are included here as well. [7]
82.1.2.32TheorySystem Services LayerThe upper layer in the BSW layer is called the System Services Layer. This layerprovides functions for the Application Layer, hence its position in the hierarchy.It contains modules for the operating system, communication services, memoryservices, ECU state management, and so on. [7]2.1.3BSW modulesThis section explains some of the modules in the BSW layer, mainly the onesused in this thesis. These modules are divided into functional groups, which areshown in Fig. 2.3 below.Figure 2.3: BSW Functional Groups2.1.4CAN Communication StackThe purpose of the CAN communication stack is to accommodate a completeCAN communication interface for the Application Layer. This means that SWC’sneed to pay no regard to identifiers, data lengths, bit timing and so on, this isall handled by the communication stack. It is comprised by several modulesfulfilling this purpose, which are shown in Fig. 2.4 below. [7]
2.19AUTOSARFigure 2.4: CAN communication stack2.1.4.1Protocol Data UnitProtocol Data Unit (PDU) is a term which describes the data of a specific communication protocol. Signals sent in a CAN communication stack are grouped inCAN PDUs which in turn are mapped to CAN frames. A CAN frame is in factalso a PDU but on the link layer, and might be referred to as an L-PDU whilethe CAN PDUs operating on the higher layers in the stack are referred to as IPDUs. These signal paths of the PDUs are routed between different modules ofthe CAN communication stack. The signal paths are routed from the COM module, through the PDU router, to the CAN interface, providing the COM modulewith means to initiate CAN data transmission, as well as receiving data at such
102Theoryan event. All communication above the PDU router is passed through I-PDUS aswell as the communication to and from the CANIf module. However, below theCANIf module, the communication is via L-PDUs. The connection of the PDUpaths is shown in Fig. 2.5 below. [18]Figure 2.5: PDU connections within the CAN communication stack
2.111AUTOSARFigure 2.6: Example of communication with PDUIn the Fig. 2.6 above, an example of the whole process of communicationthrough I-PDUs is shown. In this case we have an example of CAN data beingsent. Initially, the COM module initiates the communication process by callingthe PduR TRANSMIT() function. Due to the routing tables of the PDU routerthat have been previously configured, it is known that this data’s destinationis the CAN bus. Thus, the CanIf Transmit() function is called. Once the CANinterface has received an acknowledgement bit from the CAN receiver it willcall the PduR CanIfTxConfirmation() function, and the PDU router will call theCom TxConfirmation().2.1.4.2CAN DriverThe CAN Driver is situated at the bottom of the CAN communication stack,which is depicted in Fig. 2.4 above. The CAN driver module provides hardware access to the upper layers within the communication stack. To do this, itprovides the Communication Hardware Abstraction layer with a standardizedAPI.[18] The CAN Driver includes several hardware objects, which are used tocontrol the transmission and reception of L-PDUs. [9]2.1.4.3CAN InterfaceNext in order in the CAN communication stack is the CAN interface module,CANIf. The CANIf module is located between the Communication Services Layerand the Communication Drivers Layer in the CAN communication stack, as isseen in Fig. 2.4. As well as controlling the initialization of the CAN driver module, it also provides the CAN driver module with notification services, such as
122Theorythe function CanIf RxIndication for reception, as well as CanIf TxConfirmationfor transmission. The CANIf module acts as a user of the CAN driver module’shardware objects for reception and transmission. This makes the CANIf module independent of hardware, since the CANIf module is not accessing hardwarefunctionality directly, but instead using the CAN Driver module. [10]2.1.4.4PDU RouterFurther up in the CAN communication stack is the PDU router. The PDUR module provides routing paths within the CAN communication stack. This way, thedestination and the source of a PDU is specified. Receiving I-PDUs are routedwith the CANIf module as the source, and to an upper module in the Communication Services layer of choice as the destination. Transmitting I-PDUs are donein the reverse approach, and are routed with a Communication Services Layermodule of choice as the source, and the CAN Interface Layer as the destination.[13]2.1.4.5COMThe COM module is placed at the top of the CAN communication stack. TheCOM module handles all of the signals going to and from the RTE, as sender andreceiver signals. These signals are each referring to an individual I-PDU for thecommunication throughout the BSW layer. [11]2.1.4.6Operating systemThe OS module is part of the system services layer. The OS provides an interfacefor startup as well as the shutdown of the system. Moreover, the OS also managesthe activation/termination of tasks and the execution of these in a scheduled order based on priority. There are two types of tasks namely extended task as wellas basic task. As can be seen in Fig. 2.7 below the extended task consists of fourdifferent states, Wait state, Running state, Ready state and Suspended state. Thetask changes state depending on state transitions. The state transitions are thefollowing: Preempt, Start, Terminate, Wait, Release, and Activate. Preempt isa state transition where the task makes a transition from Running to Ready, itoccurs when the OS task scheduler starts another task with higher priority. TheStart transition occurs when a task is in the Ready state and is being selected bythe task scheduler. The Termination transition occurs when a termination of taskfunction is called, for example TerminateTask(), the task makes a transition intothe suspended state. The Wait transition occurs in extended task when the task isin the Running state but needs to wait for an event to occur. As for the activationof an extended task, it can be done for example through the usage of alarms, thiswill cause the task to enter the Ready state. These alarms could for example beset to trigger a specific event for example an event telling that a specific resourceneeded by an extended task is available. That event will trigger the extendedtask to go from the waiting state into the ready state and causes the task to beexecuted, this step transition is called Release. [22]
2.113AUTOSARFigure 2.7: States of an extended taskThere are also basic tasks which are not using events to be triggered, they aretherefore lacking the "Wait" state. This can be seen in the Fig. 2.8 below. Thesetasks will instead be activated via the triggering of an alarm or by being activatedvia other tasks. Similar to the transitions in the extended task, the basic task usesmost of them except for the ones regarding the Wait state. [22]Figure 2.8: Illustration of a basic taskIn the Fig. 2.9 below, there is an example of the execution of tasks based onpriority.
142TheoryFigure 2.9: Task prioritiesGiven these
The standard, as well as the partnership, is called AUTOSAR, which stands for Automotive Open System Architecture. The partnership was founded in 2002, initially by BMW, Bosch, Continental, DamienChrysler, and Volkswagen, with Siemens joining the partnership shortly thereafter. [6]
Google SketchUp Visualization and information handling in Google SketchUp Växjö, 2009-06-03 15 hp Examensarbete / BY9903 Handledare: Johan Vessby, Tyréns AB och Växjö universitet, Institutionen för teknik och design Examinator: Bertil Bredmar, Växjö universitet, Institutionen för teknik och design Examensarbete nr: TD 028/2009
2 DIVA 2.0 Diagnostic Interview for ADHD in adults Colophon The Diagnostic Interview for ADHD in adults (DIVA) is a publication of the DIVA Foundation, The Hague, The Netherlands, August 2010. The original English translation by Vertaalbureau Boot was supported by Janssen-Cilag B.V. Back-translation into Dutch by Sietske Helder. Revison by
DIVA Operation Manual 1 Introduction Please read this instruction manual carefully. This manual is intended for use with all Diva Weigh Only and Price Computing scales. The Diva scale is combined with a scanner for full featured Checkout applications. The Diva scale is a high precision weighing instrument.
Pre-listing Packet Get Your Diva Dwelling Sold TeamDivaRealEstate.com 206.850.3102 TheDiva@TeamDivaRealEstate.com. 2 TeamDivaRealEstate.com Who is Team Diva? . Real Trends Named Team Diva America's Best Real Estate Agents 2018 and 2019 5 Star Agent by Seattle Magazine for 13 Years in a Row
JAGUAR DIVA Runs: 0 1sts: 0 2nds: 0 Graham Rankin (Season Unknown) bd b Pat C Sabbath -Oldburrin Diva Nv'20 Ir Mrs.J.M.M.Rankin 04.May NAME CHANGED from Skirk Diva 26.May 480 4 4.47 1111 1st 6 Jaguar Puma Middle,ALed 29.62 -20 29.4 T3 Qlfyg *29.42 18.May 480 5 4.61 3333 3rd 4½ Crossfield Topaz MidToWide,EvCh 29.67 -30 29.3 T3 Qlfyg 29.73
the particularity of GUI tests automation, keyword driven test approach is introduced in this thesis. The advantages and disadvantages are shown by undertaking comparison with the Record and replay testing method and the data driven testing method. The research also includes a feasibility study of GUI tests automation.
Ida Lindh An Entrepreneurial Mindset: Self-Regulating Mechanisms for Goal Attainment Ida Lindh Entrepreneurship and Innovation Institutionen för Business Administration, Technology and Social Sciences Avdelningen för Innovation and Design ISSN 1402-1544 ISBN 978-91-7583-890-8 (tryckt) ISBN 978-91-7583-891-5 (pdf) Luleå tekniska universitet 2017
Masalah Kesehatan Laserasi kelopak mata adalah robekan sebagian atau seluruh ketebalan kelopak mata. Hasil Anamnesis (Subjective)-Keluhan : 1. Nyeri periorbital 2. Epifora-Faktor Risiko : Riwayat trauma di daerah mata Hasil Pemeriksaan Fisik dan penunjang sederhana (O bjective)-Pemeriksaan fisik : Laserasi superficial, dapat juga terjadi laserasi dalam-Pemeriksaan penunjang : - http .
