Home

Automatic verification of controller unit functions

1. 65 ENG SPEEDICAN Mo a PO je ra 66 ENG SPEED GFACAN Meni sk ok ok ok 7 KICKDOWNICAM Mar ing 1 ok ok ok ok t AYL LATERAL ACCICAN Mar sk ok 03 ok 69 STEERING WHEEL ANGLENCAN Mor sk ok ok ok 70 TraLimitDolayACAN Manitarinqit amp TraLimDelay sk ok ok ak T1 VEH_REF_SPEEDICAN Manitoring 1 qu Speed ABS sk ok ok ok T ABS_MALFNICAN ia s Speed ABSOF 33 ArbCrankShaft TrYCAN Manitarina t a ArbitratedCrankShaftTrqRioq an par S ok 495 0 on par 22 04r small dor en par 45 03 34 STEERING WHEEL ANGLEYCAN Manitarin SteerinqAnaleStatur sk sk jan par 0 05 rmall der en par 17 01 35 AES_MALFNICAN Monitarinq 1 B D ABSWarninqLamp ok sk r3 T6 FL WHEEL SPDACAN Manitarina t B v WhIFeL sk sk ak T ABS_MALFNICAN Manitaring 1 EE OFWHFrL sk 03 ok 7 FR_WHEEL_SPDACAN taring Bs v FR 03 ok ok 79 ABS_MALFNSCAN vingt Be B OFWHIFrR ok 03 sk 0 RL_WHEEL_SPDICAN Manitarinq 1 LR ok 03 ok 1 ABS_MALFNICAN Me ir Be B_OFWhIRoL 03 03 ok 2 RR_WHEEL_SPDACAr Bev WhiRoR 03 03 ok 3 ABS_MALFNICAN Me Be B_OFWhIROR sk 03 ok 4 15 M 4 E HX Diffintegration Errors Fi Difference Errors x MinMax Errors result lt Fig 8 Example of a result log file 2 7 1 Detailed analyze error logs The result file also contain sheets with detailed analyze error logs in addition to the main result page The in depth error logs are very ha
2. N A state 0 COENG_READY COENG_CRANKING COENG_RUNNING COENG STOPPING COENG FINISH eoOoococ c Fig 5 7 Time Analyze result log The analyze results are colour coded where green implies that everything is ok red colour implies that something is wrong Fig 6 contain two red marked transition transition 1 and transition 4 Transition 1 fails because the configuration file sheet signal configuration not contains information of how to parse the state parameter value 0 Transition 4 fails because 30 unfulfilled transition condition The transition condition is KL 15 1 but as seen in Fig 5 6 the current value for KL 15 is 0 0 Both this are deliberately injected errors the configuration file in 1 6 3 would not give such error The red marked fields in the time analyze result log Fig 5 7 either mean that the state wasn t found in the time analyze configuration or the time in state is below the min time or exceeds the max time Some project requires tailor made analyzes for one single purpose Fig 5 8 displays the result log of such tailor made analyze for I5D engineState state machine in the engine controller system of a Volvo diesel The only purpose for this analyze class is searching for the transition COENG RUNNING gt COENG READY and verify the transition condition if found The transition condition includes time requirements for some parameters and is therefore too complicated for the basi
3. EnginoTarque 1 0 0 19000 5 5 2000 5 5 nobdrerr 17 DrivorCrankShafeTrqRghCAN Monitaring qr2_EGtrq driverRog Out 0 0 19000 1 1 500 200 45 ahir 18 ENG_COOLANT TEMPICAN Manitaringt EGCaaltemp 1 o o N 005 2000 005 mabla 19 28 Comments 20 ENG SPEEDACAN Monitaring Es n EnginoSpood 1 0 0 800 E 1 300 200 45 ahi 21 EMG SPEED OFIOAM Meniteri gi EB QFEnginoSpood 1 0 0 3 5 5 2000 5 5 nohdrorr 22 KICKDOWNICAN Manitaring t amp KiekDaun 1 n0 104 05 2000 0 9 05 nara 23 AVLLATERALLACCICAN Monitoring _Latoralecoleration 1 o 100 05 2000 005 nohdrore 24 STEERING WHEEL ANGLEYCAN Manitarin StooringAnglo 1 o Y 05 2000 005 nabila 25 TrglimirDolayWCAN Manitarinq 1 a TralimDolay 1 0 0 100 005 2000 005 noMrorr 26 VEHREF_SPEEOVCAN Monitoringt qu Spood ABS M 0 0 10000 3 3 2000 E 3 nohdrorr 27_ ABS_MALFNVGAN Manit c SpoodABSOF 1 0 0 10000 005 2000 005 DT 2 ArbCrankShahTrqiCAN Monitaringd s ArbitratodCrankShaftTr 0 1 0 0 10000 1 10 00 200 30 abla 29 STEERING_WHEEL_ANGLENCAM Manitain _StoorinqhngloStatur 1 0 0 10000 005 2000 005 mbl 30 ABS_MALFMICAN Monitori Be DABSWarningLamp 1 3 0 30 05 2000 0 3 05 DT 3 FL WHEEL SPDVCA Bc v WhlFrL 00 0 0 2 5 5 2000 5 5 nohdrorr 32 JABS_MALFNICAN Be B_QFWhIFrL 1 3 0 303 05 2000 0 3 05 nabl 33 FR WHEEL SPDACAN Monitarina t Be v WHIFrR 0 01 h 250 5 5 2000 5 5 noMrorr 34_JABS_MALFNICAN B B OFWNFrR 1 3 0 303 05 2000 0 3 05 Bira 35 RL WHEEL SPDACAI Bev WhIRol 0 01 0 0 250 5 5 2000 5 5 ab
4. e Python module OMM LIB py e Template for configuration file e Result presentation in form of automatically generated Excel files 3 Ru T 5 Afterun 6 Shutdown Fig 1 Example of a state machine 1 2 Program module OMM_LIB py 1 2 1 Overview The library OMM_LIB py contains classes for input output handling signal processing and verification See Fig 2 for an overview of the program execution order It is possible to 48 choose what types and how many analyzes to use for the current state machine verification It is also possible to connect new analyze classes to the verification tool if the existing ones doesn t fit the current purpose Initialization Handle inputs pre Analyze Analyze do Instantiate InputHandler do Get input configurations do Instantiate Analyze classes gt do get analyze configuration do Instantiate ExitHandler do Get and parse Inca measurement do Start analyze do Write analyze to file b d Close operations do Close all open data streams O N Fig 2 State flow for state machine verification program 1 3 Analyze classes The analyze classes are responsible for verification result In other words is the choice of analyze classes for a certain analyze that decides the focus of the verification For example if the time in each state is the only thing of interest for a certain verification just instantiate the time analyze class and skip the other analyze types
5. user manuale eee ee eee eee 62 3 1 Introduction and program OVEIVISW ocoonoonoooconnconcconconncnn nono nono none ronnnnnn enne enne enne nennen nnne 62 3 2 Program ESCAPA 62 3 2 1 The module NM EIB PY cscs stevie nese nta ne ie 62 3 22 Configuration file oeste eU ROSE RISUS ESI AIR REOA D ROT DR ENTIA UAE DER EUR 63 SAUDI e E RN 63 3 2 22 NM sst te transitions cc eee teta a NI e ED UE QUE EU TAS ERU T E CENIQUN Yd Y Ree et e Ou A 63 3 2 2 3 NM state transition criterions sese eee eee 64 3 22 4 Settings for special tests ici 64 3 2 3 Sipnal Settings file oso a cn an bet Sea e einem i e QS 65 3 2 4 Power Mode settings file eene ener enne nennen enne enitn nennen nnne nnn 65 3 25 Graphical user interface eo edad nie fede US 66 3 26 Result Bile 4224s sedato esie tuc e tuit E lane tile TS 69 3 2 6 1 General NM errots osos aee DI Dp RS D ERE 69 3 2 6 2 Specific NM verification deire nennen nennen nnne nenne enne enitn nennen nnne 69 4 Controller Area Network iia 70 A A Introduction cuts pie eniedas bombe see Ma fe 70 4 2 DS A A utem inimi no EMO ste 70 AROS mo liinda e E er etg er feri HUE een ace 71 4 3 Physical li ae 71 4 3 2 Transport layer merged with Data Link and Network layer sse 71 4 3 3 Session and Presentation layer cscri irira ener VRESA nennen nnns 72 4 3 4 Application layer ied ee eee RE HE e ee ene PE Ee E se E duae 72 44 CAN frames x eda eR CR ret ie ER T RE ee ERE ER Ede 72 4 4 1 Data f
6. 14 15 16 HE 18 19 Fig 5 Example of a time analyze configuration 1 5 Result presentation A successful State machine analyze generates an Excel result log All state transition and belonging information is notated in the result log The number of sheets varies and depends on which and how many analyzes was processed The following figures Fig 6 and Fig 7 are examples of the result log 51 AAA AAA AA A NADA A A A 1 2 Ea It t paran OMMstate 1 State 0 not found in config file 5 n a gt COENG_READY KL15 1 0 6 n 0 0 7 CONDITION time 4 69622465921 2682 8 stSYS 1 0 9 n_cranking 200 0 10 n_nrmiToStart 300 0 11 t_nrmiToStart 500 0 12 113 Ti rent parar Emo 00 OMMstate 2 15 COENG_READY gt COENG_CRANKING KL15 1 0 16 n 2105 17 CONDITION time 6 476572957661503 18 n n cranking stSYS 1 0 19 n_cranking 200 0 20 n_nrmiToStart 300 0 21 t_nrmiToStart 500 0 22 23 urrent parar grae OMMstate 3 25 COENG_CRANKING gt COENG_RUHHING KL15 1 0 26 nz1178 5 27 CONDITION time 6 516651412267144 28 stS YS 0 stSYS 0 0 29 n_cranking 200 0 30 n_nrmiToStart 300 0 31 t_nrmiToStart 500 0 32 33 rreri parar grae OMMstate 4 35 COENG_RUNHING gt COENG_STOPPING KL15 0 0 36 n 819 0 37 CONDITION time 16 43576524598402 38 KL15 1 stSYS 0 0 39 n_cranking 200 0 40 n_nrmiToStart 300 0 41 t_nrmiToStart 500 0 42 OMMstate 5 45 COENG_STOPPING gt
7. S 44 Sal Software Fan 7 Download 6 fot Z E 19 Ss Ja Z A gt Initialization 4 p Operation 5 dn i 2 3 M OL A qa EN N mM d E N a x lle ES eui Operation y 4 Expulsion a NG i After run L After run i Isolated e Moe ten oe fed pect Fig 3 2 Network management base flow according to CAN NETWORK MANAGEMENT 31812308 3 3 4 Program configuration The program settings will be done in a Microsoft Excel file x s divided into three sheets NMtranistions powerMode and Signals The Excel file will be configurable by the user but with the restriction to follow a template more information about program configuration can be found in Appendix B 3 3 4 1 Main configuration file The main configuration files will be a 2 dimensional matrix with the first column and also the first row containing the state names according to specification CAN NETWORK MANAGEMENT 31812308 It will work as a jump matrix and covers all possible state transitions The cells of the matrix constitute of lists with requirements for the state transition and will be e Ifthe jump is allowed to happen e Other states that have to be entered before the transition are allowed to take place e Maximum time in state before transition takes place In fact the main configuration file s is just another representation for a fully configurationally flowing chart like the one in Fig 3 2 in section 1 5 2 but with
8. time in each state is the only thing of interest for a certain verification just instantiate the time analyze class and skip the other analyze types then There are also good possibilities to extend the class library with new types of analyzes The existing analyze types are created after a generic implementation method and as long as the new analyze class follow this method it will be recognized and handled in a correct way by the OMManalyzer class A analyze class must contain the functions described in Table 5 2 Table 5 2 Function declaration for the Analyze classes Function Description getConfiguration Gets the necessary information from the configuration file startAnalyze Starts the analyze of the chosen parameter vectors extracted from the Inca log file resultHandler Organizes the result from the analyze and writes it to a new excel sheet 5 1 2 5 Configuration file The Excel configuration file must at least contain two sheets one with information what signals to extract and process from the log file and another with the state machine architecture Fig 5 3 and Fig 5 4 display how the above mentioned Excel sheets can look like 27 KLIS 1 n n_cranking n 0 stSYS 0 n gt n nrmlToStart KLUB 0 0 0 Fig 5 3 Example of how the state machine architecture is constructed in the configuration CoEng_st ETKC 1 OMMstate T15_st ETKC 1 Epm_nEng ETKC 1 time StSys stStrhETKC 1
9. when the time efforts are big enough to cover for the model development and simulator configuration 1 2 Background Volvo Car Company have asked for more efficient but still reliable methods for car software verification with the aim to test as much as possible in simulator environment in the future Previous work has been done at VCC This thesis will complement their work 1 3 Purpose and aims Along with the electronic networks in cars increases both in size and complexity the demanded work for verification of new electronic solutions increases as well To meet the requirement of a continuously increased workload without increasing the human resources new and more time efficient methods must be developed Verification of CAN functionality is an area where automatic test processes can be implemented with in this connection quite small effort The thesis will result in a collection of tools for analysis and verification of CAN logs The aim is to develop software tools with high precision reliability and flexibility 1 4 Outline of thesis This report will focus on verification of three different controller unit functionalities e CAN Interface e Network Management e State machines in general 1 4 1 CAN Interface Every node connected to any of the vehicles controller area networks CAN bus have a CAN interface The interface handles all data traffic between the nodes and CAN bus Sometimes the node requires another data
10. CoEng nThresCranking CXETIKC 1 n cranking CoEng nThresNrml2Strt CAETIKC 1 n nrmlToStart CoEng tiNrml2Strt CAETKC 1 t nrmliToStart Fig 5 4 Example of signal configuration to the left How the state parameter will be parsed is configured on the right hand side Note that the logical transition conditions in Fig 5 3 follows python and most other programming languages as well notation For example implies the sign assignment and equal to The following operators can be used Or not Also remark that the parameters fetched from the Inca log file is renamed to shorters and more intuitive names for example names used in the specification from the controller system supplier 28 In addition to the two sheets mentioned above the configuration file can include more sheets with configurations for other analyzes Fig 5 5 displays how the configurations for the time analyze can look like The times in each states are specified in seconds 1 means no limitations COENG STANDBY COENG READY COENG CRANKING COENG RUNNING COENG STOPPING COENG FINISH i e on o ro oooo0ono Cn ca gt No ory N er Fa rs ns GD 141001 On t CO gt e Fig 5 5 Example of a time analyze configuration 5 1 3 Result presentation A successful State machine analyze generates an Excel result log All state transition and belonging information is notated in the result log The number of sheets v
11. Let s now be a bit more specific and focus on software verification There are always a number of things that have to be analyzed when releasing new software Both the functionality and the interaction with other softwares have to be analyzed As an example it does not matter if the functionality for the cars light system follow specification if it disturbs the immobilizer and make it dysfunction The old school method and often the standard way to verify a certain implementation is to analyze it in a real car This method is excellent for some types of analyzes for example drivability and acceleration tests On the other hand verification tests like turning the start key from ignition on to ignition off a couple off hundred times are not ideal to do in a real vehicle Therefore Volvo and other car companies for a couple of years ago started to use simulation systems which purpose is to mimic all from specific components to whole vehicles for test and verification Volvos simulation system is called HIL Hardware In the Loop and is delivered from the German company dSpace The name comes from the possibility to add hardware like gear sticks and control boxes in the simulation loop To do a test in the HIL system requires up to date simulation models and relevant simulator configuration Sadly there are often very time consuming both to create and compile new simulation models and tune the simulator Therefore it s only motivated to run simulation tests
12. Operation to Off A a AAA A e p eo S a E A A O 8 LT B REN SER TO T E S L O A v w 2 FromTo Reserve Off Start wp Commun Operas Bus Off Transmi Silent Wake up Wake up m md mm Pran Bas Off Can Cos Operation After r Expulsic Reserve Reserve Stopped 3 Reserred x x x x x x x x x x x x x x 4 ore x Ades x ARICA AROJC Sp aed x x AMA Nes x x AH NHAU ALCA Adz0 JCal x x PUTAS 5 start p x x x x x x x x x x x x x x x Sa Soltware KR Mep x Mep AJ tJC AJ t JC AJ 0 JC x x x js OCs Ade m T x x Ais 0C iA NET MGMT a L x x T Operation x Ades x ADG AJet JC5L AJetJC Alee x x T x AJz0 JC AJz0 JCz Mep AJ 0 JC x x 8 Bus Off x Ades x Mep AJ tJC AJ 1 JC x x 5 10 G 4x x Alps Adat ICL Mel T Meded x x 3 Transmission Discommect x Mep x Mep AJ 0 JC AJ t JC AJ 1 JC 1 x x AJ 0 JC AJ 0 JC x x AJ 0 JC Mep AJ 0 IC 1 JT 0 AJ 0 JC x x 10 Silent x x x x x x x x x x x x x x x x x x x x x N wake ep Network x x x x x x x x x x x x x x x x x x x x x LR Wake up Pending x x x x x x x x x x x x x x x x x x x x x 13 Expulsion x Mep x AJ20 JC AJ 0 JC AJ t JC Ast Cel x x x AJ tJC AJ 0 JC x x Appl Aste AJsO JCs H UTsO AJefiCs x x AdstJCs A JT253 14 Isolated x Alsace x AJ20 JC AJzOICs AJetUCs AJ 0 IC x x x AJ 0 JC AJetCs x x App AJ 0 JC AJ 0 JC 1 JT 0 AJ 0 JC x x Ada JO AJT 53 15 Expulsion Silent x x x x x x x x x x x x x x x x x x x x x 16 Expulsion Diagnose x x x x x x x x x
13. Python programming lan oua ge REIR RBS I Se ites eo ooh dase 10 palm 10 2 2 Why Python In L c caido 11 PPS HO D TT CR ape 11 222 SE IL Te EA AEE E E O E E A O E A 11 2 23 Rapid application development ie rer E SERERE Gee EE A 11 2 24 Cross platform ON csi 11 2 2 5 Internet develOpitig O 12 AA cn REN RE p CROP RH eap egre r detentus 12 2 3 Why Python In automatic testing at VOLVO sse eene nennen nennen nnne 12 2 3 1 PowerTrain test automation PTTA ssssssesessesseeeereer eene oap nnne nennen nnne 12 2 3 2 Reasons for using Python for PTTA eee 12 3 Scripts for automatic verification and result presentation sese 13 3 1 State machine verification Theory sse eee enne enne enne enne entere enne nenne 13 3I Introduction hie teat A iesu 13 BL I2 theoretical oVetvIe Ws sonia eb ad bent bo tt Abtei 13 3 1 3 Programconfigur tion a este een ed pi etate nee e ii e d eeu des 15 3 1 3 1 Basic Analyze configuration siae e tl en 15 3 1 3 2 Time Analyze configuration ener trennen nro rennen enn nennen enne nnne 15 31 3 3 Signal configuration ias 16 EL Verific tion Methods 22 e e eee led eon ed e Gr eese Medettales 16 3 2 CAN Interface verification Theory sees 16 3 23l IntFoduetioh c lotic neo eer ad oed d RR d ie rae rrt t ee PE e nd tp Ett TS 16 SDD Theoretical OVervIeWs ioc ee t ad d e t tb t atte ee etes 16 3 24 Sipnal prO
14. Showing all errors 0 errors in total c o In addition to the result log plots are also automatically generated for signals that didn t pass the verification processes Plots are a very good complementary to the result file when it s hard to decide if the verification shall pass or fail See Fig 5 15 for an example 36 DriverCrankShaftTrqReq CAN Monitoring 1 gs2_EGtrq_driverReq 300 T T T T 100 es Ue oe z A A ee 50 0 10 20 30 40 50 60 time s Fig 5 15 Example of two signals that didn t pass the verification processes It s not hard to understand why it failed 5 2 5 Discussion 5 2 5 1 Program functionality The program works as far at it has been tested as intended The implementation runs in the way it was specified It takes some time to be comfortable with the program and its mechanics the demanded user inputs are quite big The main focus during development was flexibility rather then user simplicity The program will exclusively be used by an analyze and verification group at Volvo car company who required a program for handling more or most all the CAN interface verification The need of a simple to use program for everyone was therefore non existent 5 2 5 2 Known problems and bugs There are at least two major problems with automated CAN interface verification e Handling big Inca measurement logs in combination with many verification parameters may allocate all RAM e Verify pair of param
15. at least contain two sheets one with information what signals to extract and process from the log file and another with the state machine architecture Fig 3 and Fig 4 display how the mentioned Excel sheets can look like KL15 1 n n eranking n n nrmiToStart KLIS 0 0 0 CoEng_st ETKC 1 OMMstate T15_st ETKC 1 Epm_nEng ETKC 1 time StSys_stStrt ETKC 1 CoEng_nThresCranking_C ETKC 1 CoEng_nThresNrml2Strt_C ETKC 1 n nrmlToStart CoEng tiNrml2Strt CAETIKC 1 t_nrmlToStart Fig 4 Example of signal configuration to the left How the state parameter will be parsed is configured on the right hand side Note that the logical transition conditions in Fig 3 follows python and most other programming languages as well notation For example implies the sign assignment and equal to The following operators can be used 50 e and e or e not Also remark that the parameters fetched from the Inca log file is renamed to shorter and more intuitive names for example names used in the specification from the controller system supplier In addition to the two sheets mentioned above the configuration file can include more sheets with configurations for other analyzes Fig 5 displays how the configurations for the time analyze can look like 1 2 COENG STANDBY 0 3 COENG READY 0 E 4 COENG CRANKING 0 50 5 COENG_RUNNING 0 50 6 COENG STOPPING 0 50 7 COENG FINISH 0 15 B g 10 E a 13
16. input before the analysis can be done Fill in the right configuration file address CAN log address etcetera For an example of a correct configured GUI see Fig 6 CAN Interface analysis DAR CAN log adress e g YXCAN interfaceXCAN in 14 dxl get adress Configuration file adress e g YACAN_interface configuration txt get adress Result file destination e g Y CAN_interface Result bt get adress Start verify Fig 6 Example of a correct configured GUI When all inputs are correct just click the start verify button to start the verification If everything went as intended the entry box in the GUI now should contain a simple text log see Fig 7 58 CAN Interface analysis CAN log adress e g YXCAN interfaceXCAN in 14 dxl get adress Configuration file adress e g YXCAN interfaceiconfiguration bt get adress Result file destination e g YXCAN interfaceYResult bxt get adress Start verify Scanning CAN log CAN log scan completed Reading settings Configuration completed Analyzing CAN log CAN log verification completed Writing results to file Result sucessfully saved 00 Fig 7 Example of a successful CAN interface verification 2 7 Result File A successful CAN interface analysis generates a result log saved in Microsoft Excel xls format The result log both contains used configuration and verification result The first table
17. part 2 4 3 OSI model The OSI model divides data communication in seven layers for a more foreseeable representation see Fig 2 The layers are all linked together one level receives data from a lower level and distributes it up one level The OSI representation for Controller Area Network follows below THE 7 LAYERS OF OSI TRANSMIT E i Transport layo Network layer Data link layer Physical layer Fig 2 OSI model 4 3 1 Physical layer Defines how the signals are transmitted Handles signal levels bit representation and transmission medium 4 3 2 Transport layer merged with Data Link and Network layer e Data Link layer takes care of error correction and handles the flow control The layer can be divided into two sub layers Media Access Layer MAC and Logical Link Control LLC The Network layer packs data together and administrates the routing The Transport layer keeps track of the packages sent and retransmits those who fail In a Controller Area network these layers handles the following tasks o Fault confinement o Error detection 71 Message validation Acknowledgement Arbitration Message framing Transfer rate and timing Information routing O O O 0 50 O 4 3 3 Session and Presentation layer Structure the messages for the intended application Message filtering and handling handles the status as well 4 3 4 Application layer The main interface for end user 4 4 CAN
18. part of the result file presents all general Network Management errors It can be all from an illicit transition to wrong powermode or unidentified states In addition all passed states are presented in the order they were activated 5 3 4 2 Specific NM verification The log file s second and last part contains the result of the special tests Each match of the specified state series is presented Whole or part of the series can either be marked as ok in green colour or as failed in red colour Failed means time in state whether is below the minimun time limit or exceeds the maximum time limit 5 3 5 Discussion 5 3 5 1 Program functionality The program works as intended as far at it has been tested The implementation runs in the way it was specified The by far biggest risk when using the program is wrong configurations set by the user according to specification But the program will exclusively be used by an analyze and verification group at Volvo car company and flexibility was therefore prioritized instead of use ability It takes some time to be comfortable with the program and its mechanics the demanded user inputs are quite big The main focus during development was flexibility rather then user 43 simplicity and a program that can handle more or most all the Network Management verification The need of a simple to use program that everyone can use for verifying the Network Management was therefore non existent 5 3 5 2 Kno
19. purposes aims and delimitations for each of the different verifications The program modules State machine CAN Interface and Network Management verification will be created in Python 2 2 and its standard libraries It will be implemented in the Power Train Test Automation PTTA tool and there constitute the last chain in the test and verification process In addition a stand alone user interface will be created for the opportunity to do verification outside the PTTA environment With a stand alone GUI it will be much easier to distribute test versions for debugging and evaluation Also Interfaces to flexible generic tools like Inca are needed for gathering sufficient program input 4 1 General program parts Some parts of the program is used in all verifications and will therefore be introduced here and not together with rest of the program description 4 1 1 Inca as CAN logger The program Inca developed by the German company ETAS will be used for logging the Controller Area network Inca can be connected to the CAN bus or directly to a node through several different interfaces depending on sample rate requirements and available contactors However the log file will have the same appearance disregard sample rates independent of the logging method which of course is an advantage and will make this project easier to 21 handle What internal node respectively external CAN parameters to log can be individually configured in In
20. representation than what is used on the bus and vice versa Therefore mathematical operations like scaling multiplication and offset addition subtraction are implemented in the CAN Interface 1 4 2 Network Management Network management is a way to control that a node always are in correct operation mode according to the network status Key out Operation and After run are examples of network statuses Network management takes the network status as input and supervises the node operation mode 1 4 3 State Machines Network management is an example of a quite complicated state machine A car node can contain a lot of different state machines with purpose to supervise that one or more functions is in correct operation mode 2 Python programming language Python is a dynamic scripting language for Rapid Application Development RAD The background and basics for Python and also why it is used in VOLVO simulators is discussed in this chapter 2 1 Introduction Python is a high level dynamic programming language formally made by Guido Van Rossum in 1991 Python was from the start decided to be an open source product it means the source code is free and available and also possible to further develop for everyone Python has grown fast and a big group of voluntaries are involved in the development As many other modern languages it s a high level object oriented language and very similar to for example Perl and Ruby in respect to the
21. settings is a copy of the configuration file The second table result contains the verification results The left most column declares if the verification passed or failed The main reasons for adding the settings table are to store both configuration and result at the same place and the possibility to compare the configuration with the out coming result For an example see Fig 8 59 Parametert Parameter2 Scale Offse Maz Differance small derivative IntError small derivative Derivative breakPoint Difference big derivative IntError big derivative Mapping PEDAL POSXCAN Manitarinqi Ec ILAccPodalPar 1 o wo 18 1 2000 18 1 vebl BAROMETRIC_PRESSURENCAN Manitarin s AmbiontPresrure o Y 10000 D 05 2000 o 05 noBdreee Ec_To_AmbTemp 1 gt 100 D o 2000 D 02 neBdrese AmbTempOr 1 D 3 D s 2000 D 05 eira AvailGrankShaftTrqMax CAN Manit bleCrankShafeTrqMax oA 200 10000 4 3 2000 4 3 vebl AvailCrankShaftTraMintCAN Mani bleCrankShafeTeqMin of 20010000 4 3 2000 4 3 vebl ERAKE PEDAL PRESSEDICAN Maritrin Es E_ErakePodalActivo 1 D 1 or oz 2000 os 02 e i CCActivACAN Mu VeDo B CCActive D 1 D 05 2000 D 0 5 vabi 15_D_COMade 0o m D 05 2000 D 05 neBdrese CCOverriddenMCAN Monit VeDo B CCOverriddon D 1 D 05 2000 D 0 5 nodrorr O0SetSpeedSCAN Manitarin WeDe_v_COSetSpoed o z5 1 05 2000 1 0 5 noBdrese OC TracFarcoReg
22. the operating speed is higher than the built in math support in Python The language also supports unlimited mathematical precision For example two very large numbers can be added without using a third party language 2 2 2 Text processing Text processing is easy handled in Python Any data can be split separated summarized and reported There are built in modules to read log files line by line summarize the information and then write it all out again Python actually comes with SGML HTML and XML parsing modules for reading writing and translating With the support of many other languages text processing engines and flexible object handling Python becomes a good choice for Text processing 2 2 3 Rapid application development The high level and fully dynamic language architecture combined with the less is more syntax approach it goes very quickly to develop applications in Python In addition the extensive module libraries that comes with Python provides interfaces to many common protocols and tools Another aspect of rapid development in Python is the ability of fast program evaluation The code doesn t have to be linked and compiled but run as it is through the interpreter Also the debugging is easily handled in the same shell and environment as the programming 2 2 4 Cross platform development Python is available for all major operating systems Windows Linux Unix Mac Amiga among others and supporting them in a completely
23. to the parameters in the parameter file Uses a zero order hold algorithm to interpolate empty samples getPointedCanMatrix Merges the extracted columns from getPointedCan Vector pCanMatrixVerification Verifying the network management getStatelnTime Extract the network management state for a given getLastValue Extract the last network management state in the Can log appendLog Adds a text string to the result file 39 5 3 3 Configurations 5 3 3 1 Main configuration sheet The NMtransition sheet is as mentioned in 1 5 4 1 a documentation of criterions for all possible transitions The left most column contains the from states while the first row contains the to state See Fig 5 17 for an example Note that the cells are unexpanded In addition to the transition matrix it also contains a table for activation or deactivation of tests A test is searching for a specific combination of transitions specified in the configuration file in the sheet with the same name as the test For example configurations for the test Bus off can be found in the sheet named Bus off A ELA de La een o H p E t e e t e ee n Le e A ed De e Ju end 28 NTL R Er ap gna v pana 2 FromTo Reserve Off Start up Commun Operati Bas Off Transat Silent Wake ap Wake up Expulsic Izolatec Expalzic Expulsic Bus Off Can Con Operation After r Expulsic Reserve Reserve Stopped 3 Reserred x x x
24. transition criterions The state transition criterion can either contain the character x or a string of the same type as in Fig 4 NM settings From To Rese Off Startup Comm Operati Bus CTransi Silent Reserved x x x x x X X x Off X AJ 1 JC 1 JT 50 x AJ 1 J AJ 0 J0 AJ 1 AJ 0 J x Start up X X x x x x x x Communication Software Init X AJ 1 J AJ 1 JC AJ 1 AJ 0 J x Operation X AJ 7D J AJ 1 JC AJ 1 AJ 1 J x Bus Off X JE AJ 1 J AJ 1 JC AS AJ 1 Jx Transmission Disconnect X AJ 1 JC 1 JT 50 x AJ 71 J AJ 0 JC AJ 1 AJ 1 J x Silent X x x x x x x x Wake up Network X x x X X X X X Wake up Pending X x X X X X X X Expulsion X AJ 1 J0 1 JT 50 x AJ 0 J AJ 0 J0 AJ 1 AJ 1 J x Fig 4 Part of NM configuration file head sheet NM state transition criterions from Operation to Off are red marked If the transition criterion between two states is x marked means the transition can t be done It can for example be from or to a non used state in a specific implementation In Fig 3 the transition from or to the Start up state are marked with an x because that NM state isn t used in the example implementation the same goes for Reserved and a number of other NM states If the transition criterion contains a text string like the red marked one in Fig 3 the analysis will use that string as input The text string contents with descriptions are listed in Table 2 In fact the text strings follows the Python notation and are therefore ideally
25. x x x x x x x x x x x x x x x x x 4 jort x Ahir x Adet JCs AJ 0 JC AMEL Ads0 Csl x x x Ad O JC AJ 0 JC x x AdsOuCs AJEHIC AJsO JCs M TsO AJsQuCel x x AdstJC 1 7 53 L5 _ Start ep x x x x x x x x x x x x x 6 Communication Software Init x Midd x x x Ad x D O AJOC x x T Operat x AdstiCs x x x Ad x Ads 250 Adz0 JC l x x 8 Bss Off x Meded x x x Aelel AJC x x Med AJEJC A 50 Mid x x 3 Transmission Disconnect x AdetCs x x x Adz0 JC AJ 0 JC x x Adz0 JC Ast JC AJsO JCs TzO AJsQuCe x x 30 Silent x x x x x x x x x x x x x x x x x x x x x M Wake ep Network x x x x x x x x x x x x x x x x x x x x x 12 Wake up Pending x x x x x x x x x x x x x x x x x x x x x Ls Expulsion x AdstJC x AE AJ 0 JC AHEL AHEL x x x AdstCs AJ 0 JO x x AdsOUCs AJ 0 JC AJsO JCs TsO AJsfUCs x x Ads CAI T 53 14 Isolated x Meded x A102 AJ 0 JC AEL AJ 0 JCH x x x Adz0 JC AJ t CH x x Adz0 JC AJ 0 JC AJsO JCs TzO AJsQuCe x x AdstCs A JT253 5 Expulsion Silent x x x x x x x x x x x x x x x x x x x x x 16 Expulsion Diagnose x x x x x x x x x x x x x x x x x x x x x Tt Bes Off WaittAfter ren x Altes x AdtCs Adz ICL AJ t ICL AdetilCs x x x AJIJ ALG x x Ada JC Mep AJetJCe M JTS53 AJeUCs x x Alt JCAL T 53 18 Can Controller hit hitializal x AJstiCs x Alt dy x x As Cs x x Ads 0 AJ0JCs x x Ade TES 1 Operation After ran x AdstJC L x At JC l KGL AJ 1 JC x x x AJ 0 JC AJ 0 JC x x Ads AJ 0 JC x x 2
26. 0 Expulsion After ren x AJstCz x AJ tJC AdztJC AJzfJCz x x x Adz0 JCz AJz0 JC x x AdstJCs x x 21 Reserred x x x x x x x x x x x x x x x x x x x x x 22 Reserred x x x x x x x x x x x x x x x x x x x x x 23 stopped x AdetCs x ASC Apa AJetuC Ast C C x x x AdstidCs AJetCel x x Aled Asp AJfJC M JTS58 AECA x x AJA JOAN ST 53 24 25 26 ar 28 Type of test Facit ONIOFF 23 Buc off BusOff OFF 30 Tres Test2 ON 9t Testa Test3 ON 32 Expulcion Expulzion ON 33 Testa Ten OFF 34 Test5 Tests ON 35 36 31 38 39 40 F 18 5 17 Network management main configuration sheet From To Rese Off Startup Comm Operati Bus CTransi Silent Reserved x x X x x x x Off AJ 1 JC 1 JT 50 x AJ 1 J AJ 0 JC AJ 1 AJ 0 J x Start up x x x x X X X Communication Software Init Operation Bus Off AJ 1 J AJ71 JC 4J 1 AJ 0 J x AJ 0 J AJ 1 JC AJ 1 AJ 1 J x AJ 1 J AJ71 JC A71 AJ71 x SE S x R 24 2X 2X4 R4 0X 0X Transmission Disconnect AJ 1 JC 1 JT 50 x AJ 1 J AJ 0 JC AJ 1 AJ 1 Jx Silent x x x x x x x Wake up Network x x x X X X X Wake up Pending x x x x x x X Expulsion X AJ 1 JC 1 JT 50 x AJ 0 J AJ 0 JC A71 AJ71 x Fig 5 18 Part of NM configuration file NM state transition criterions from Operation to Off are red marked The state transition criterion can either contain the character x or a string of the same type as in Fig 5 18 If the transition criterion between two states is x marked means the t
27. 0 00 80 18 1 0 on pos 17 245 small der 0 00 80 18 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 485 small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 49s small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 495 small der 0 00 0 00 10 on pos 54 435 small der 0 00 0 00 10 on pos 54 435 small der 0 00 0 00 10 on pos 54 50s small der 0 00 0 00 10 on pos 54 50s small der 0 00 0 00 10 on pos 54 50s small der 0 00 0 00 H CCActive C AN Monitoring 1 VcDe B CCActive Showing all errors 0 errors in total M 4 E M Diffintegration Errors Difference Errors MinMax Errors result Fig 5 14 Part of a difference errors log 5 2 4 2 Plots 1 CCMode CAN Monitoring 1 Vc D CCMode Showing all errors 0 errors in total lt J CCOverridden CAN Monitoring 1 VcDe B CCOverridden
28. 23 43 1 Backetound ss a E A or MH EN I M HM a tes eee 23 4 32 Purpose and arns 5s tem bete Sen beet C ite Nel ES 23 4 3 3 Delimitations eie teet reet i ER Ee e HU et eed e nete e eee edet 24 4 4 Network Management program eee ee eee eee 24 4 4 Backeground eee ee e c Ug RR eR Oe d ete 24 4 4 2 Purpose and aiims dde 24 44 3 Delimitations eerie re ee ee ci ge tede eb ee diede ve 24 SICH 25 5 1 Result State Machine Verification oooocconnnoncocononcncnonnnnononanononnnanononancno enne eene ONET ORE Raees 25 5 1 1 Result overyiew ie dece tec e e eR ee ee e ede eee Edd eden 25 5 1 2 Program module OMM LIB PYocoooncccnoninonoonnoonconnconoconoon nooo ncon nono nn nre n rre enne enne 26 5 1 2 1 Class InputHandler teet eie dei eli e ee dee e deae 26 5 1 2 2 Class ExitHandler iiec tectae eee ede ie ipee ene dee eene cede 26 5 1 2 3 Class OMManalyzer ied ect Heo ee eee dei ede Ute ee Ee Oe 26 3 1 2 4 Amalyzeclasses ete Reich ee t erede ce etude e a a 27 2 1 2 Configuration file 5 4 ite ia rw A eu ae ie RH Te Ge PU Wee IIT 27 AS Result presenta aii See ere ie tse dE a eee a e e GP td 29 Asl DISCUSSIOf de ee ve ae reti twee ats 31 21 41 Program t nctionality 5e E e a P eem 31 5214 2 Known problems and bugs e ew tea e tee Eh en a ei we eig 31 KIR CONCHISIOM seai ai eh oes O E E ate echt ses aed AO dese oi esse eed a gee 31 IO E ture Work ere Re Sure S ch
29. 4 0 State 16 0 No matches 24 Match Statt Time End Time State 4 0 State 16 0 State 20 0 No matches Match Start Time End Time State 4 0 State 6 0 State 11 0 State 4 0 30 Match 1 7 079403679 1892752442 ok ok ok ok Match 2 14 01948953 3135526472 ok ok ok ok 32 Fig 11 Example of a result log file 3 2 6 1 General NM errors The first part of the result file presents all general Network Management errors It can be all from an illicit transition to wrong powermode or unidentified states In addition all passed states are presented in the order they were activated 3 2 6 2 Specific NM verification The log file s second and last part contains the result of the special tests Each match of the specified state series is presented Whole or part of the series can either be marked as ok in green colour or as failed in red colour Failed means time in state whether is below the minimum time limit or exceeds the maximum time limit 69 4 Controller Area Network 4 1 Introduction The Controller Area Network CAN was first designed for the automotive environment but is nowadays also used in other applications The transfer protocol sends on a two wire data bus which often are twinned for better noise reduction It has during the years experienced three major updates see Table 1 For maximal transfer rate the wiring can t be longer than 40 meters A wiring of double length results in about half the transfer rate Table 1 The different Co
30. B s 2000 gt G 5 KICKDOIINCAN Manara Kiba 1 a as 2000 a G 26 AYLLATERAL_ACCICAM Mar inq s Loteral amp ccelorat 100 O os 2000 g 0 5 naAdrorr 2T STEERING WHEEL_ANGLESCAN Moni ing nglo 100 v os 2000 D 0 5 no ideorr 25 TraLimiDolay s CAN Manitarinqi imDelay 3000 D 95 2000 D 0 5 no deorr 25 VER REF SPEEDACAN enira 36006 3 gt 2000 3 Sader STATES Te P o as 2000 o Pe Pa 36006 o os 2000 D P 22 TRR ana ETT 10000 o os 2000 o US waders 33 ABS MRLFMCAN Tene Seo AS mina amp 3 02 os 2000 a2 P SITES Bv WHF 256 s E 2009 B Een 35 AES MALTWACAN Heniterin EOI gt a as 2000 33 OS nados 35 FRLWHEEL_SPO CAN ta EC E s E 2009 s Gl G or B a3 as 2000 32 Herma 3 RL WHEEL SEDICAN Haniveri T E B B 2000 B Sabre 39 AES MALTIICAN M nitarin1 Era gt 33 as 2000 p US hanna 40 RR WHEEL SPDYCAN Menitarina t Bev WhiioR 250 5 5 2000 5 5 nafidresr Cat JABS MALFIRCATe Horaris BeLELOFWhiReR E 32 as 2000 pH US narra Le 2 47 Parameteri Parameter Maz Difference IntError es PEDAL_POS Can Henitoring paas pS Tis eanomerrio_PRESSURENCAN Meniterin c AmbiontP rorrure se Im 50 Ambion TempSCAt Monitering E po s St ambienttomporcan 5 STD GA Crank Share Bien TX 5 lavai m 54 BRAKE PEDAL PRESSEDICAN Hen EE PPRT TA TRI mn S5 eGActioe CAN Hon a mn Sk CCMeeACAN Mentorina 1 Pa rm r1 S1 CGOwsriddontCANMantaringd epo B GCOverridden 1 2 SISTR URS F3 a 59 CCTrasarceRe CAN Manharingi s CsTrasfarseRea F1 S Taan Ture reoi SR nk Shaft
31. CAN and node activities The program provides the user with possibilities to choose what signals to analyze sample rate scaling offset etcetera The log file can be saved either in ETAS own format dat or in a common ASCII txt representation 4 3 2 Purpose and aims Manually analyzing the CAN interface is very time demanding today and will be even worse in the future along with more complex CAN network layouts The aim will be to create a reliable automatic verification model with the purpose to considerable decrease the time demanded for CAN interface verification The task will be done by implementing a new function library in the scripting language Python which are able to handle and analyze ASCII log files from Inca Another aim is after a successful development use the CAN interface library in a simulation environment which automatically will generate an Inca log file for the chosen simulator settings 23 4 3 3 Delimitations It will hopefully be few delimitations when the function library are finished The Python scripts will be close but never able to cover every possible kind of CAN parameter verification One of the main reason is to hold down the complexity of the from user demanded configurations and settings Another problem that may occur is slow performance and allocation of all available RAM when using big log files e g many samples and or parameters in combination with many parameters for verification 4 4 Net
32. CHALMERS Automatic verification of controller unit functions A practical approach DANIEL SWANSON Division of Automatic Control Automation and Mechatronics Department of Signals and Systems Chalmers University of Technology G teborg Sweden 2008 EX050 2008 Abstract When verifying car controller unit software each software function is often verified individually The verification is a very important part before the controller unit can be used in production Invalid controller units can cause big damage to the cars vital parts engine or gearbox Or even worse the car can become highly dangerous in traffic situations Until today the controller units has been verified manually This thesis prepares a new method for automatic verification of controller unit functions The automatic verification programs are written in the scripting language Python and implemented in a simulator environment called HIL Hardware In the Loop The aim is to develop and supply a totally automatic simulator where controller unit functions can be tested under different kinds of predetermined driving and environment circumstances The automatic simulator tests generate in the end log files for manual study The only works for the user with correct configured simulator and verification settings is just to start up the process and afterwards study the result logs which contain all required test information The results after tests with a series of
33. COEHG FIHISH KL15 0 0 46 n 0 0 47 CONDITION time 16 88530671017221 48 n stSYS 0 0 49 n_cranking 200 0 50 n_nrmiToStart 300 0 51 t_nrmiToStart 500 0 52 Fig 6 Basic Analyze result log N A state 0 COENG_READY COENG_CRANKING COENG_RUNNING COENG_STOPPING COENG_FINISH 00000 Fig 7 Time Analyze result log The analyze results are colour coded where green implies that everything is ok red colour implies that something is wrong Fig 6 contain two red marked transition transition 1 and transition 4 Transition 1 fails because the configuration file sheet signal configuration not contains information of how to parse the state parameter value 0 Transition 4 fails because unfulfilled transition condition The transition condition is KL 15 1 but as seen in Fig 6 52 the current value for KL 15 is 0 0 Both this are deliberately injected errors the configuration file in 1 6 3 would not give such error The red marked fields in the time analyze result log Fig 7 either mean that the state wasn t found in the time analyze configuration or the time in state is below the min time or exceeds the max time 1 6 User Interface This verification tool will be implemented in the power train test automation PTTA program and its graphical user interface PTTA is a tool for automatically generate and verify log files for different operation conditions decided by the user In other words it take
34. Cessihip o dt eee eet PR COTES Rd e O 17 ID Venificati n methods ti iE ee I dre ei dote He ret tiu ita 17 32 5 A Difference VENCIO c potet ee eed ete et eg eerie le Pe En eret area ses 17 3 2 5 2 Integrated difference verification sss sees eee eee 17 2 2 5 3 Mim Max verification is a aaae a ia aree ted 18 3 2 6 Program configuration TTT 18 3 3 Network Management verification Theory sese ee ee eee eee eee 18 3 3 1 Introduction A a etie n e e eres 18 3 3 2 Theoretical Overview iu ooa teen tb Here liner PH bei es e rt e Ee res 18 3 3 3 Required states and modes base flow sese sese 19 3 3 4 Program config ratiofi 5 esce ete ette ded i e e Pee idad 20 3 3 4 1 Main configuration file ecce aida 20 3 3 42 Power mode configuration ceci idee nein rn eee ER e Reed 20 3 3 4 3 Signal configuration eee edes eite ie tee de Hn e eee Pee de Ed e eine dn 20 3 35 Verification methods A e eee feeder 21 A uti ME ER 21 4 1 General program parts rie eet ite tei eee i Re d ed e Eee Te eed 21 4 1 Inca as CAN logged 21 41 2 Program conferat One 3 eere Re RIT e E E COR ETU RS 22 4d 3 Result presentation eee SRI RETI RR I DE aes Ru S ee e EPA EY 22 4 2 State Machine pro GREEN RAI RII oe UR UN R ORTI DERE RT ers 22 4 2 Background set sei coset tese Rua OST e aeta aee Re aS 22 A 22 KT TTT ORAT We ER ae tit ete tette vn ce aei e ei 23 A D 3 R He aee ee ee tee AL 23 4 3 CAN Interface OM gere ee d eec me ree tede e d edet tede inus
35. Operation PM 2 3 4 5 6 7 Bus Off PM 2 3 4 5 6 Transmission Disconnect PM 2 3 4 5 6 Silent PM 2 3 4 5 6 Wake up Network PM 2 3 4 5 6 Wake up Pending PM 2 3 4 5 6 Expulsion PM 2 3 4 5 6 Isolated PM 2 3 4 5 6 Expulsion Silent PM 2 3 4 5 6 Expulsion Diagnose PM 2 3 4 5 6 Bus Off Wait After run PM 2 3 4 5 6 Can Controller Init Initialization PM 2 3 4 5 6 Operation After run PM 2 3 4 5 6 Expulsion After run PM 2 3 4 5 6 Reserved PM 2 3 4 5 6 Reserved PM 2 3 4 5 6 Stopped PM 2 3 4 5 6 Fig 5 19 Example of a Power mode settings file 41 5 3 3 3 Signal settings Also the parameter settings are configured via the Excel Sheet Sginals The left column contain the python program parameter name while the right column contains the respective CAN log address See Fig 5 20 for an example NM signal S Type of parameter Parameter name Time time NM state diag NW States CCP 1 PM keyPos or likely PowerMode Fig 5 20 Example of a signal settings file 5 3 3 4 Settings for special tests As mentioned in 1 6 3 1 there are a number of special tests Each of these tests has its own configuration sheet see Fig 5 21 for an example The special test configurations contain a three column table The first column specifies what combination of states to search for The other two columns specifies min and max time in each state State Min Time Max Time 5 3 6 3 6 10 2 5 10 Fig 5 21 Bus off test configur
36. The remote frame has the same appearance as the data frame but with the RTR bit set to 1 recessive and no data field 4 4 3 Error frame The error frame consists of two bit fields error flag field and error delimiter The error flag field consists of superposition of error flags from different network stations The error flags can be divided in active and passive flags An active error flag is transmitted by a node detecting an error while a passive error flag is transmitted of a node detecting an active error flag 4 4 4 Overload frame The overload frame contains of 2 bit fields overload flag and overload delimiter Transmission of the overload flag occurs if the internal conditions of a receiver require a delay before the next frame or if a dominant bit is detected during the intermission The overload flag consists of six dominant bits the overload delimiter of eight recessive bits and is of the same type as the error delimiter 73
37. TraOFVCAN Ma 30 0 on par 0 02s small der on par 17 01 DriverCrankShafeTeqhe SCAN Mani 198 danger 2208 mall dor enpar 22 01 ES ENG COOLANT TEMP CAN Man Y E S S ENG SFEEDICAN Haritri g a ig z EE ENG SPEED GFYCAN Meni Kai s x oe Se 1 tckbowINCAN He S adieu E E G a E Es STEERING WHEEL ANGLESCAN Mon de rt CS slay iCAN Menitaring L e js ok T1 VEH REF SPEEDACAN Monitarin au2 Speed ABS sk sk sk sk TE AES MRLFRACAN Maniarin ql Rr LTE Harder s 195 on par pedii PTT T4 STEERING WHEEL ANGLENCAN Mani 71 6 an par 0 037 rmall dor en par 17 01 T5 nes MALFIRGAN Monito Fs 2 FL WHEEL SFDICAN Mmi SR E EOI se ri BISOMMRR se E SET Mn aT SEO rm ocn Eon m M 4 E M Diffintegration Errors A Difference Errors Z MinMax Errors result lt Fig 5 13 CAN interface verification results for a Jaguar car The result file contains three more sheets in addition to the result sheet e Integrated difference diffintegration errors e Difference errors e MinMax errors The additional sheets contain detailed verification logs Fig 5 14 shows an example of a difference errors log 35 Showing all errors 0 errors in total F G E JavailCrankShaftTrqMin CAN Monitorir BRAKE_PEDAL_PRESSED CAN Monit c Availab
38. VA Configuration file reete tiet estie eie ci eee e Hee RE RN 50 5 Result present tton ite eee eite e e cde Ue eee e eee debent vn 51 1 6 User Interface recedere ded eet eie d ede d ee e e asec 53 2 CAN interface verification user manual eene enne nre nennen nennen 54 2 1 Program overview escena eee eee desi ite fee ede E E eee eene ede iia 54 Fig 1 UML flowing chart for the CAN interface verification algorithm eee 54 2 2 Delimitation Se 5 ase eee e ERR I ON E REN Re eU ded ate e teu Sa 54 2 3 C ANinterfaceLIB module iii TR eae iem ten ae t iiie iet 55 2 4 Contigurationfile 4 ere tr De Re ATI e a iet uen as dee tis 55 2 4 1 Parameters NN 55 2 42 Scalig ee e de tse dee S n ATI e Ge CEN tiu d en denk td sos 56 2 43 OPS CE sca cn t a deer Ore ree ee ed etie ie edere d diei uec caw NN 56 DAA MIMI OE 56 2 4 5 EI Eee ae reat aie e aet eie ala ttu ta 56 24 6 O Beka 56 2 4 T Dernivative breaking pott s oe eere lie e he eret te Gv cette s 56 pa Dupin 57 2 4 9 Comments in configuration tile eere to e e e OR e a te teda 57 2 5 Mapping tables ou e etate ae e eva a EG e eterna e ag rue e destin edt 57 2 6 Graphical user interface aee e teret a d WR a ee EP OO eg RED a emt e t 57 DA Result Fl 59 2 1 1 Detailed an lyze Error A A eds 60 3 Network management verification
39. additional state transition criterions 3 3 4 2 Power mode configuration The power mode configuration sheet constitutes of lists with allowed power modes for each state Power mode can very briefly be described as the electrical status of the car 3 3 4 3 Signal configuration The program needs three CAN parameters as input e Network management state status e Power mode status e Time status The parameter input configuration sheet provides the python program with names of the above parameters in the current CAN log This feature can t be hard coded since different nodes use different parameter names 20 3 3 5 Verification methods The verification process will check if the network management CAN parameter follows the user specifications in the main configuration file The verification algorithms will cover following sources of error e Not allowed transition e Time limit exceeded before state transition e Not allowed state transition due to not have entered other state or states first The verification points above are quite straight on but maybe the last point needs an explanation For example if more than one network management state has to be entered during the node initialization the transition criterion for entering the operation mode will be that all initialization states has been passed through 4 Program This chapter is partly about what general program parts are needed for the automated testing and partly about
40. adress e g YANM alllnOneXCAN in 14 dxl get adress Configuration file adress e g YANM alllnOneWWMalllnOne xls get adress Result file destination e g Y3NM alllnOneYResult bxt get adress Start verifyl Scanning CAN log CAN log scan completed Reading settings Configuration completed Analyzing CAN log CAN log verification completed Writing results to file Result sucessfully saved Fig 10 Example of a successful Network management verification 68 3 2 6 Result File A successful Network Management analysis generates a Microsoft Excel result file All upcoming network management errors during the verification are presented in the result file In addition the last part of the log contains results for the activated special tests See Fig 11 for an example log A B C D E F G 4 Type of error From state To state Time 5 Transition from to a non declared state 2705s B Transition from to a non declared state 47 08s 7 Wrong powerMode mode 6 0 7 15s 8 Not allowed transition 11 8 98s 9 Not allowed transition 4 14 025 10 Wrong powerMode mode 6 0 14 09s 11 Not allowed transition 11 18 95s 12 Not allowed transition 4 24 02s Ha Wrong powerMode mode 6 0 24 095 re Of DEN 1 1 1 i i 1 15 Passed States 16 Unknown NM state 255 0 0 0 2 0 4 0 6 0 11 0 4 0 6 0 11 0 4 0 Exe le O 0 Match Start Time End Time State
41. and tolerances 1 Parameterl Parameter2 Scale Offset Min Max Differance small derivative IntError small derivative Derivative breakPoint units s Difference big derivative IntError big derivative Mapping 3 PEDAL POSICAN Monitoring 1 Ec IL AccPodalPar 1 0 018 1 200014 1 bilat 4_ BAROMETRIC_PRESSUREICAN Manitarin c AmbientProrrure M O 10000 005 2000 005 nabl 5 _ AmbiontTomp CAN Manitaringt Es To Amblomp 1 o o 100 002 2000 00 mbl amp JfmbientTompQFICAN Manitaring skinet 1 0 0 3 005 2000 005 naMrorr 1_ AvoilGrankShaftTrqMax CAN Monitaring t AvailabloCrankShafeTegl 0 1 0 200 10000 1 4 00 Y nohdrorr AvoilGrankShaftTeqMinSCAN Manitaring c AvailabloCrankShafeTegl 0 1 0 200 10000 4 3 2000 4 3 nohdrorr 4 BRAKE_PEDAL_PRESSEDACAN Monitorin Ec_E_BrakoPodal ctivo 1 0 010 02 2000 0 4 H DT 10 O0ActiveACAN Manitaringt Meo B CORctve 1 ooo 4 005 2000 005 D H CCMadoACAN Monitoring 1 We D_CCMado 1 o w 05 2000 005 nabl 42 CCOvorriddoniCAN Manitarinq 4 VeDo E_CCOvorriddon 1 0 1 05 2000 905 nabl 143 COSotSpoodiCAN Manitarinq d WeDo v COSotSpood 1 o h 250 105 2000 105 nohdrore 44 COTracFarceRoghCAN Monitaringst a OcTracForeeRioq 1 0 O 40000 005 2000 005 nabl 45 CrankShafeTrq GAN Manitarin gs EsTa EnginoTarquo 1 30 10000 1 1 200 200 45 ahli 16 GrankShaftTrgQFICANMonitaringt
42. aries and depends on which and how many analyzes was processed The following figures Fig 5 6 and Fig 5 7 are examples of the result log 29 S O A A E AA A A O EE 5 n a gt COENG_READY CONDITION m COEHG READY gt COENG_CRANKING 1 CONDITION nn cranking co COENG_CRANKING gt COENG_RUNHING 27 CONDITION stSYS 0 COENG_RUNHING gt COENG_STOPPING 37 CONDITION C KL15 COENG_STOPPING gt COENG_FINISH 47 CONDITION n re ro me 47 El 22 23 24 E ES E El El 30 32 3 34 E E sr 36 El El rat El 44 45 46 Ea 48 El E E 52 Fig 5 6 Basic Analyze result log OMMstate 1 KL15 1 0 n 0 0 time 4 69622465921 2682 stSYS 1 0 n cranking 200 0 n_nrmiToStart 300 0 t_nrmiToStart 500 0 OMMstate 2 KL15 1 0 nz210 5 time 6 476572957661503 stSYS 10 n cranking 200 0 n nrmiToStart 300 0 t nrmiToStart 500 0 OMMstate 3 KL15 1 0 n 1178 5 time 6 516651 412267144 stSYS 0 0 n_cranking 200 0 n_nrmiToStart 300 0 t_nrmiToStart 500 0 OMMstate 4 KL15 0 0 n 819 0 time 16 43576524598402 stSYS 0 0 n_cranking 200 0 n_nrmiToStart 300 0 t_nrmiToStart 500 0 urrent pare OMMstate 5 KL15 lt 0 0 n 0 0 time 16 88530671017221 stSYS 0 0 n_cranking 200 0 n_nrmiToStart 300 0 t_nrmiToStart 500 0 State O not found in config file
43. as program input Table 2 NM state transition criterions Variabel name Description AJ Stands for Allowed Jump Equal to 1 means allowed transition Equal to 0 means not allowed transition JC Stands for Jump Criterions Contains a list with states which must have been entered before transition If no criterions the list will only contain the single value 1 JT Stands for Jump Time Contains the maximum time for the transition to be done 3 2 2 4 Settings for special tests In addition to the transition matrix the main sheet also contains a table for activation or deactivation of tests A test is searching for a specific combination of transitions specified in the configuration file in the sheet with the same name as the test For example configurations for the test Bus off can be found in the sheet named Bus off There are a number of special tests Each of these tests has its own configuration sheet see Fig 5 for an example The special test configurations contain a three column table The first column specifies what combination of states to search for The other two columns specify min and max time in each state The configuration of a special test is saved on an own sheet in the configuration document The sheet name must be the same as the name of the test 64 State Min Time Max Time 5 3 6 3 6 10 4 5 10 Fig 5 Bus off test configurations 3 2 3 Signal settings file The parameter settings file should be
44. ations 5 3 3 5 Stand alone user interface See Appendix B for a brief description of the simple stand alone user interface 5 3 4 Result File A successful Network Management analysis generates a Microsoft Excel result file AII upcoming network management errors during the verification are presented in the result file In addition the last part of the log contains results for the activated special tests See Fig 5 22 for an example log 42 w N 4 Type of error From state To state Time 5 Transition from to a non declared state 2 7 06s B Transition from to a non declared state 4 7 08s 7 Wrong powerMode mode 6 0 7 15s 8 Not allowed transition 11 8 88s 9 Not allowed transition 10 Wrong powerMode mode 6 0 11 Not allowed transition 12 Not allowed transition 13 Wrong powerMode mode 6 0 14 15 Passed States 16 Unknown NM state 255 0 0 0 2 0 4 0 6 0 11 0 4 0 6 0 11 0 4 0 17 19 Match Start Time End Time State 4 0 State 16 0 22 No matches 25 Match Start Time End Time State 4 0 State 16 0 State 20 0 26 No matches 27 29 Match Start Time End Time State 4 0 State 6 0 State 11 0 State 4 0 30 Match 1 7 079403679 1892752442 ok ok ok ok 31 Match 2 14001948953 3136626472 ok ok ok ok 32 33 Fig 5 22 Example of a Network Management result file 4 14 02s 14 09s 11 18 85s 4 2402s 24 09s a AOD AOD EKA G 1 1 1 i i i 5 3 4 1 General NM errors The first
45. be replaced by either a single frontslash or double backslashes se Jo o a a len Parametert Parameter2 Scale Offset Min Maz Differance small derivative IntError small derivative Derivative breakPoint units s Difference big derivative IntError big derivative Mapping PEDAL POSACAN M 1 o 0 wors 1 200014 d sabir EAROMETRIC PRES 6 10000 005 2000 005 o 100 Dr 2000 002 0 3 005 2000 005 200 10000 15 4 200 30 200 10000 4 3 2000 4 9 108 02 2000 0 8 02 DEC kShafeTraMin CAN EDAL_PRESSEDICA ShaftTral 0 1 E E OFWMIFIL Be WMFER 0 01 Bc B_OFWHIFR Bs s WhiFiol 0 01 B lt _B_OFWhIReL o 303 05 2000 0 3 os Bev WhIROR o o 250 2000 36 AES MALFMNCAN 9 303 0 5 2000 0 3 95 E lt _B_OFWhIReR Fig 5 10 Example of a correct CAN interface configuration file 3 2 6 4 Mapping tables The mapping tables constitutes of a simple Excel sheet The mapping tables are used for mapping one or more values to other values For example this functionality is needed if the internal parameter who sample the gear selector use the values p r n d and the CAN dito uses the numbers 0 1 2 3 instead Fig 5 11 and 5 12 are examples of how a mapping table looks like Mapping From To From To p 0 2 0 150 r 1 3 0 2700 n 2 4 0 3000 d 3 Fig 5 11 Mapping table Example Fig 5 12 Anoth
46. c analyze to handle A m E CES 1 I5Dspecial Result No COENG RUNNING gt COENG READY transitions found Fig 5 8 Result log for I5D engineState tailor made analyze 5 1 4 Discussion 5 1 4 1 Program functionality The program works as far at it has been tested as intended And the implementation runs in the way it was specified The class library that exists today will probably not cover all types of future state machine verifications but the program controller is well prepared for implementation of new analyze classes It takes some time to be familiar with the program user interface but is anyway probably constructed in simplest possible way A flexible program with big configuration possibility always demand some time effort of the user before it become a strong and time saving tool 5 1 4 2 Known problems and bugs No bugs or problems detected But new types of state machines will most likely require additional new developed analyze classes But it s more a limitation rather than a problem The program needs a better evaluation before confirming that it is free from bugs 5 1 5 Conclusion The state machine verification program works very well It is fast flexible and in this connection easy to use A lot of responsibility is given to the user A configuration miss can 31 cause verification errors or even worse not detecting state machine bugs and errors But that s the price to pay for flexible solutions Develo
47. ca A rule of thumb when creating Inca log files for automatic verification is less is more since a smaller log file will be faster to process The log file will by default be saved in dat format When recreating the measurement in MDA which is ETAS signal analyzing tool the dat file is interpreted by a database In this way the log file becomes quite small but for our purpose it s better to export the dat file to an ASCII file txt since Python contains powerful tools for processing text files The log file generated by Inca need some processing before it can be used in the verification algorithms First of all Inca samples the time vector faster than the measurements are sampled the measurement vectors contains therefore a lot of empty sample points that have to be handled before any mathematical processing can be done The best and simplest way is to interpolate the missing sample points For this project a first order hold algorithm linear interpolation will probably be the best compromise between precision and calculation capacity The empty sample points before the first measurement will be deleted 4 1 2 Program configuration The program serttings will be done in a Microsoft Excel file The configuration file will not have the same appearance for every verifiaction method The configuration file is the only program flexibility there is The file is parsed into the program through Microsoft Windows COM Interface 4 1 3 Result pre
48. controller unit functions indicate great time profits But also many pitfalls and demand high user competence and a good knowledge of the underlying algorithms to interpret the result logs in a correct way Nomenclature Term Controller Area Network CAN Engine Controller Module ECM Transmission Controller Module TCM Description Network protocol and bus standard that allow controllers and devices to communicate with each other and without a host computer CAN node designated for steering of engines CAN node designated for steering of automatic transmissions Acknowledgement The master thesis project was carried out at Completed Driveline department 97567 at Volvo Car Corporation in Gothenburg Sweden The author wishes to acknowledge the support from supervisor Runar Frimansson at department 97567 Volvo Car Corporation as well as the support from other members from department 97567 The author also wishes to thank the examiner Jonas Fredriksson at Department of Signals and Systems Chalmers University of Technology Gothenburg Absttact A ier inei a ia 2 Noinencl ture 2 bouem rere a a aia 3 Acknowledgement at e i 4 L Introduction i RI a ner op ie e Oe e ERE ete E QURE ERUE cia endl 8 1 2 Background see eee RR ee e P E HE e ERU seu Ue ERR HR Ee FR Ee de Tete OS 9 1 3 Purpose and aims ii RE Ie de Tete 9 LA Outline OF i DRE 9 TAI CAN Interface A a assi 9 14 2 Network Mad ist 9 1 4 3 State Macs cid 9 2
49. d a mapping the corresponding mapping address cell should contain the string NoAdress 2 4 9 Comments in configuration file The configuration file in Fig 2 contains a comment string comment Comment strings can only be done in the first column and must be declared with double number signs 7 Comments can for example be used to sort different kinds of parameters in different groups 2 5 Mapping tables Mapping lists are used for parameter remapping The lists are linked to the parameters through the configuration file see section 2 2 7 A mapping list contains information of how the mapping should be done see Fig 3 and 4 for examples Remark if Inca logs an integer as float you have to handle it like it s done in Fig 3 From To 2 0 150 3 0 2700 4 0 3000 From To p 0 r 1 n 2 d 3 Fig 3 Mapping table Example Fig 4 Another mapping table example 2 6 Graphical user interface The CANinterface LIB py is provided with a stand alone user interface GUI py Through the interface users can execute CAN interface analysis with different settings Fig 5 shows the interface start screen 57 CAN Interface analysis E Jes CAN log adress e g YACAN interfaceCAN in 14 dxl get adress Configuration file adress e g Y ACAN_interface configuration bet get adress Result file destination e g YACAN_interfaceiResult bd get adress Start verify Fig 5 User interface start screen The program need some
50. e the raw data in a local variable getSignalsMatrix Process the raw data interpolate empty samples etc and extracts parameter vectors according to the configuration file and save it as a 2 dimensional matrix openConfigWorkbook Sets up all connections with the Excel application and open the configuration file 5 1 2 2 Class ExitHandler The class ExitHandler saves the result and closes the used applications i e Microsoft Excel Does not contain any callable functions everything is done when the class is instantiated 5 1 2 3 Class OMManalyzer The class OMManalyzer is the program controller It instantiate the other classes and handles the function calls OMManalyzer doesn t contain any functions itself which means the verification process starts when the class is initialized and in the end produce a result file without any other lines of code The OMManalyzer needs 4 arguments e Address to the Inca log file e Address to the Excel configuration file 26 e Address to the result destination e Alistof names on what types of analyzes to instantiate and run OMManalyzer will automatically instantiate InputHandler ExitHandler and the chosen analyzes It also does the necessary function calls for each initialized class 5 1 2 4 Analyze classes The analyze classes are responsible for verification result In other words is the choice of analyze classes for a certain analyze that decides the verification focus For example if the
51. e working load increase Cut down the time for each verification process to handle the increased working load Evolve and make the verification processes more efficient The aim is to create a reliable automatic state machine verification tool with purpose to considerale decrease the time demanded for state machine verification The task will be done by developing a log file processing tool in the language python The final goal is a proper and well working implementation of the verification tool in the simulation environment used on VGC 4 2 3 Delimitations The aim is to build a very dynamic and adaptable Python class library But there will of course be delimitations that the user most have knowledge about The most important delimitations are shown above e All node parameters that are used by the state machine most be able to log e The program scripts can only verify logical expressions of parameters with same time stamp i e logical expressions with not synchronized parameters can t be handled However it s in most cases possible to handle this types of limitations by expand the basic class library with a new class tailor made for the current task 4 3 CAN interface program 4 3 1 Background The can interface is verified today by manual studying of the parameter behavior during different types of operations and condition settings either in real time or via a log file Volvo car Corporation uses Inca among others for logging the
52. er mapping table example 5 2 3 Stand alone user interface See Appendix A for a brief description of the simple stand alone user interface 5 2 4 Logging result 5 2 4 1 Result file A successful CAN interface analysis generates a result log The result file contains information of both the settings and result The first table is a copy of the configuration file and the second table contains the verification results 34 Parameter Parameter2 Scale Offse Min Maz Differance small de ative breakPoint Difference big derivative IntError big derivative Mapping PEDAL POSYCAN Hari Kaar A 2000 te L T BAROMETRIC PRESSUREICRI Haritrin s AmbiontPracrure 5 gt 56006 2000 o Pe Zl OE 1 s we 2000 E Poa 3 ambienTompOricalManiterimad eT 1 Y 2000 E 5 it Jost shah ACA Henri rare Bag aa 200 mn 2000 4 bss fvailOrankshaltTrqMin CAN Mesitering vla Crank Sha Trin E 200 10000 2000 4 3 neBdres 42_ BRAKE_PEDAL_PRESSED CAN Monitorin Ec_B_BrakePedalActive 1 D 2000 cx 0 2 nohdrors 33 eoaeticet GR VDE Cosa 1 Een o US nados coma Pa w Een D US nados E RRs Een E GE R 250 2000 1 GE 0008 2000 D GE Em 2000 s C a I 36006 2000 E GE 20 DriverCrankShateTrqhe CAN TC open 36006 2006 E 2 21 ENG COOLANT TEMP CA Monieringt E60 200 2009 o SS Ere rap 23 ENG SPEEDICAN Henitering Tan tnginoSpood sos 3s w 500 20 4 naires 24 ENG SPEEO_QPICAN Manivoringl ERa 3
53. er and responding parameter on the CAN bus and compare them 3 2 4 Signal processing Sometimes two parameters with the same behaviour but different gain and or offset have to be verified with each other Therefore functions for scaling and offset have to be implemented In some special cases a parameter need to be remapped to fit and be compared by another parameter For example some parameter vectors contain letters that must be remapped to number values to be processed A mapping table will be used for that issue 3 2 5 Verification methods The main purpose with the can interface will as mention above be to compare internal node parameters with the extern CAN dittos Therefore some fast due to the possibility of big amounts of samples and or signals and reliable algorithms for comparing digital vectors is required 3 2 5 1 Difference verification The difference verification just subtracts the two signal vectors element vice If the difference in any sample point is to big the verification will fail How big the difference can be before the verification fails will be tuneable by the user and also individual for every pair of vectors This method is very fast intuitive and easy to understand it will hopefully also be good enough for most signals Some signal differences may have problems with spikes due to lag between intern and extern parameters signal interpolation etcetera and will therefore be hard to handle with an algorithm wit
54. eters which are asynchronous in time and contain big variations with rapid changing Big measurement logs 100Mb and above in combination with many verification parameters mean a lot of sample points to read and process which takes time for the Python interpreter to process It can also result in allocation of all free RAM which will decrease the 37 system performance a lot Unfortunately the automated and in most cases very comfortable memory allocation in Python doesn t handle this problem in the best of ways Python is fast for being an interpreting language but not comparable with compiled languages such as C In addition in C all memory allocation is controlled by the programmer Maybe the Python code can be optimized due to execution time in some points but will then be much harder to grasp and edited Comparing two parameters with bad time synchronisation and rapid changing will lead to big difference errors and even sometimes a fair difference integration error It means the user must be aware of the approximate look and behaviour of the tested parameters when tuning the allowed error levels A more sophisticated signal processing would probably partly handle this problem but on the other side lead to a longer execution time This is over all a minor problem and a very few parameters are affected compared to increase the execution time further The program is designed to run on a windows platform with office 2003 installed I
55. evelopment process It s without question the heaviest argument when convincing the possible user to change working methods Other important parameters are of course reliability storage functions flexibility etc but not nearly as important for the user as the time profits The configuration and first run for a whole new controller unit independent of it s verification of CAN interface network management or the engine state machine will take about the same time as to test it manually In other words it will take 4 hours or more dependent of software type of function for verification coverage etc The big time profits are instead received when iterating the verification process for example when a new software update is released Usually a controller unit last for 3 6 years That implies plenty of software updates in general 40 50 updates a year With that basis just a single hour time profit when using automatic verification methods is a huge time save 45 6 3 Problems and pitfalls There are of course apart from the benefits also several problems and pitfalls with using automated verifications The biggest source of error for manual verification is without doubt the human factor But I will say the same goes for automatic verification if the algorithms itself is verified in a proper way It can be everything from incorrect configuration to wrong result interpretation But of course the tester must be aware of program flaws even if
56. frames The transmissions on the Controller Area Network are divided into frames and can be configured for two different CAN formats CAN 2 0A or CAN 2 0B CAN 2 04 only supports a CAN base frame with a length of 11 bits for the identifier while CAN 2 0B supports an extended base frame with a length of 29 bits for the identifier CAN 2 0B is compatible with CAN 2 0A but not vice versa To separate base frames from extended frames an IDE bit is used dominant 0 for base frames and recessive 1 for extended frames The CAN network has four different types of frames Data frame Containing data a node wants to transmit Remote frame Requests the transmission of an identifier Error frame Frame for detecting an error Overload frame Frame for add some space between other frames 4 4 1 Data frame The Data frame are used for data transmission between the nodes and has different designs for CAN 2 0A 11 bit identifier and CAN 2 0B 29 bit identifier Table 2 describes the base data frame format and Table 3 the extended data frame format Table 2 Base frame format 3 Field name Length bits Purpose Start of frame 1 Denotes the start of the frame Identifier 11 Data identifier used for handling the buss priority Remote Transmission Request 1 Must be dominant 0 Optional RTR Identifier Extension bit IDE 1 Must be dominant 0 Optional Reserved bit r0 1 Reserved bit Data Length Code DLC 4 Numbe
57. fully dynamic system approach and autonomy memory management The python language aren t focused on something special but trying to be comprehensive without delimitations A high level language means that it contains structures which allow the programmer to execute advanced operations without detail knowledge what s lying behind A single command can open a data stream or show a picture That implies big advanced functions can be developed in rapid speed The price the programmer has to pay for not using a low level language is the loss of total control in every implemented instance As mentioned above things like memory allocation are automatically handled by Python which are very comfortable in most cases but still is a trade off where the opportunity for total control lose Python is an interpreting language The Python code is interpreted to machine code first when the program is running line by line The opposite is a compiling language as C and Pascal which code must be translated to machine code before the program can be executed The advance with an interpreting language is better flexibility and faster development With better flexibility means for example dynamic object typing the type can change while the program is running The down slope is slower executing comparing to a compiled language The problem if it s a problem can partly be circumvent by developing C or other low level language code for the time critical application and link i
58. higher tolerance for integrated differences due to badly synchronised signals and therefore two configuration parameters for integrated signal differences are needed 3 2 5 3 Min Max verification Controlling minimum and maximum values is another verification that has to be done The verification will be done after signal processing and therefore only one minimum respectively one maximum value are required for each pair of signal vectors 3 2 6 Program configuration The program configuration will be done in a Microsoft Excel file x s It will contain possibilities to define what parameters that should be tested but also the opportunity to adjust and tune the verification tolerances individually for each pair of parameters 3 3 Network Management verification Theory 3 3 1 Introduction The network management specifies how a CAN node should interrogate and behave during all possible types of running conditions A dysfunctional network management can cause serious problem and it s of great importance to cover all kind of running conditions during the verification process For example the node must limp home and use safety settings when the environment does not work as intended or enter appropriate after run states when turned off Unfortunately it takes time to run network management test and analyze test logs To cut the time for test log analyzing a module for automated network management verification has been developed 3 3 2 The
59. hout any type of low pass filtering The algorithm contains three by the user configurable parameters e Maximal difference when signal derivative is low e Breakpoint between low and high derivative e Maximal difference when signal derivative is high Signal parts with big derivative sometimes require a higher tolerance for differences due to badly synchronised signals and therefore two configuration parameters for signal differences are needed 3 2 5 2 Integrated difference verification The integrated difference verification integrates the difference of the vectors in intervals of one second each The maximum allowed value for the integration difference error over a one second interval will be tuneable by the user and individually for each pair of vectors This verification method is more forgivable for short difference spikes than the method described in 1 5 3 1 but will maybe fail 1f the difference has a small but acceptable level all the time In other words the standard difference verification are searching for peaks and bigger differences while the integrated difference verification are searching for small but steady signal deviations The algorithm contains three by the user configurable parameters e Maximal integrated difference when signal derivative is low e Breakpoint between low and high derivative e Maximal integrated difference when signal derivative is high Signal parts with big derivative sometimes require a
60. iCAN Manitaring s OcTracorceFioq 0 10000 D 05 2000 D 0 5 nodrorr CrankShaftTrq CAN Maniterir Ec Ta EngineTarqve 0 10000 5 5 2000 5 5 vebl CrankShaf Te OFACAM d EngineTarque 0 10000 5 5 2000 5 5 no drorr DrivorCrankShaftTrqRioq CAN Monitaring yr2 EGtra_driverfiog 10000 5 5 2000 5 5 no drorr ENG_COOLANT_TEMPACAN Manitarinq t EGCaeltomp o 200 D 05 2000 D 0 5 vabi Comments ENG_SPEED CAN Monitaring Es n Engine Spoed o 000 25 10 500 200 48 no drorr ENG SPEED OFICAN Ex E_OFEngine Spoed D 3 5 5 2000 5 5 ebar KICKDOVIMCAN Me KickDaun D 1 08 05 2000 os 0 5 nofidreer AYLLATERALACCICAN Manitaringt lt Lotoraliccelora o wo D 05 2000 U 0 5 nofidroer STEERING WHEEL ANGLENCAN Maritarin lt _Stocringfingle o wo D 05 2000 D 0 5 no amp drerr TralimitDelayACAM Manits lt TralimDelay o 100 D 05 2000 D 0 5 noBdroee VEH_REF_SPEEDICAN Ma o 10000 3 3 2000 3 3 vebl ABS MALFINCAN M 9 10000 D 05 2000 D 0 5 no amp drerr ArbGrankShofeTraVGAN Mowi 10000 D 05 2000 D 0 5 no amp drerr STEERING WHEEL ANGLENCI in s Stooring nglo rara 10000 D 05 2000 D 0 5 no amp drerr ABS MALFINCAN Moritori Ez D ABSWarninaLamp D 3 03 15 2000 03 0 5 no drorr L FL_WHEEL_SPDIOAN Mani Bev WhIFrL o 350 5 5 2000 5 5 nodrorr 35 JABS_MALFNICAN B B_OFWhIFrL D 3 03 as 2000 0 05 eira FR_MWHEEL_SPDACAN jd Bau WhiFrR o 20 5 5 2000 5 5 no drorr ABS_MALFNICAN Bs E OFUMFHR D 3 03 as 2000 02 05 vabi RL WHEEL SPDACAN Menitaringi Beb o 250 5 5 2000 5 5 naAdross ABS_MALFNIOAN i B
61. irit and will hopefully be flexible enough to analyze and verify also future State machines Network management and CAN interface architectures But software tools with high flexibility as everything else also has a seamy side the demand of competence and experienced manpower for handling the program configuration To learn and master PTTA is sadly not the only obstacle It also requires adaptation of a whole test environment namely the car to a simulated ditto That requires of course great efforts from the developers of the simulator and its surrounding environment to get things work in a proper way but also from the users They have to change or in many cases try new ways of working This thesis has only been about verification of three different types of controller unit functions and it maybe seems like verify these collection of functions in a manual or automatic way doesn t matter But that s wrong at least from two very important perspectives First these three are somewhat the absolutely most time consuming functions to verify especially the CAN interface And the verification has to or at least should be done with every new software update Second hopefully this thesis in combination with the other parts of PTTA works as a good example and guidance for future work 6 2 Time profits The time savings for using automatic verification methods instead of manual must be managed as the very most important parameter during the whole d
62. it s well tested One of the most important qualities for the tester to possess is the capacity for estimate the reliability of the result just because it s so easy to inject an error in the configuration 6 4 The importance of satisfying specifications A prerequisite for automatic verification of controller unit functions is good and exhaustive specifications Of course good function specifications are also required 1f the verification is done manually but it doesn t have to be crystal clear in every single way A manual test is allways and will allways be much more flexible than automatic tests If something are not clear or not mentioned in the specification of the function the manual tester in many cases can decide if the function is ok just by using his her logical mind and experience The function will of course not follow the specification to hundred percent but it s at least working That flexibility will never be reached by using automatic tests An automatic verification algorithm contains as much intelligence neither more or less as required for verifying that the implementation follows specification In the very most cases a bad function specification leads to bad or useless automatic test results T Future Work The future work in the automated software verification area is endless This thesis combined with the PTTA development is just a first step in the right direction and guidance for future strategies But if we just foc
63. ition may not be the same condition as when cranking is stopped i e it is possible to crank when engine is running 14 T4 Normal stopped not KL 15 HW and n lt n stopped T5 Afterrun finished Time FanReady Diagnosis Ready MemStore Condition is engine and supplier dependent T6 Stalled n n stalled and then set StalledRecoverReady INT sets for next cycle T7 ECM reinitialized StalledRecoverReady INT T8 Cranking Deactivated Manual Cranking not KL 50 HW and n n start crankstoped or Startblocking INT Automatic Cranking not Cranking INT and ncn start crankstoped This condition may not be the same condition as when cranking is stopped i e it is possible to send engine state cranking when the starter motor has stoped cranking and the engine is not fully running T9 Shutdown Afterrun finished INT T10 Shutdown Not WakeUp HW and not Started INT In line with Fig 3 1 a state machine not contains conditions for all possible kinds of transition The states not connected with a line are handled as not allowed transitions under all circumstances 3 1 3 Program configuration The program settings will be done through a Microsoft Excel file x s The Excel file must at least contain the basic state machine information i e states allowed transitions and transition criterions But the file can also provide classes that run more specific analyzes with configurati
64. l 36 AES MALFIRCAMH Be E OFIWRUL 1 3 0 38 05 2000 03 05 DT 3T RR_WHEEL_SPONCAN ql BURE n 0 0 2 5 5 2000 5 5 nobdrerr 38 AES MALFICAN Monitoring Be E OFUWRLR 1 3 0 38 05 2000 0 3 05 DT 3 4 4 amp e Fig 2 CAN interface configuration file 2 4 1 Parameters The first two columns in the CAN configuration file contain the test parameters Parameterl is tested against the contiguous Parameter2 It s advisable to let the parameter names in the configuration file be exactly the same as in the Inca CAN log to avoid problems If the 55 parameter s corresponding value vector contains literals they have to be mapped please read section 2 2 7 2 4 2 Scaling The third column in the CAN configuration file contains information of how Parameter2 will be scaled The scaling algorithm is very simple Parameter2 is just multiplied with the scaling value For example if the scaling value is 3 Parameter2 will be three times as big as the original Scaling value one means no scaling at all 2 4 3 Offset The forth column in the CAN configuration file contains information about the offset for Parameter2 The offset just adds to Parameter2 For Example offset value 40 means the vector values corresponding to Parameter2 all will be lowered with 40 Offset equal to zero means no offset 2 4 4 Min Max Column 5 6 contains the minimum respectively maximum value for Parameterl and Paramter2 The min max evaluation for Paramete
65. leCrankShaftTrqMin Ec B BrakePedalActive Showing all errors 74 errors in total 10 on pos 17 21s small der 0 00 0 00 10 on pos 1721s small der 0 00 0 00 10 on pos 1721s small der 0 00 0 00 10 on pos 1721s small der 0 00 0 00 10 on pos 17 21s small der 0 00 0 00 0 00 0 00 1 0 on pos 17 225 small der 0 00 0 00 10 on pos 17 22s small der 0 00 0 00 1 0 on pos 17 22s small der 0 00 0 00 10 on pos 17 22 small der 0 00 0 00 1 0 on pos 17 22s small der 0 00 0 00 10 on pos 17 22s small der 0 00 0 00 10 on pos 17 22s small der 0 00 0 00 10 on pos 17 225 small der 0 00 0 00 10 on pos 17 225 small der 0 00 0 00 1 0 on pos 17 225 small der 0 00 0 00 10 on pos 17 225 small der 0 00 0 00 10 on pos 17 0 00 1 0 on pos 0 00 1 0 on pos 17 22s small der 0 00 0 00 1 0 on pos 17 22s small der 0 00 0 00 1 0 on pos 17 23s small der 0 00 0 00 1 0 on pos 17 235 small der 0 00 0 00 10 on pos 17 23s small der 0 00 0 00 10 on pos 17 23s small der 0 00 0 00 1 0 on pos 17 23s small der 0 00 0 00 1 0 on pos 17 23s small der 0 00 0 00 1 0 on pos 17 235 small der 0 00 0 00 1 0 on pos 17 235 small der 0 00 0 00 10 on pos 17 235 small der 0 00 41 03 10 on pos 17 24s small der 0 00 80 18 10 on pos 17 24s small der 0 00 80 18 10 on pos 17 24s small der
66. llowed powermode column contains a list follows Python notation with allowed power modes The list must contain at least one element 3 2 5 Graphical user interface The NM LIB py is provided with a stand alone user interface GUI py Through the interface users can execute network management analysis with different settings Fig 8 shows the interface start screen Network Management Analysis DER e g YANM alllnOneXCAN in 14 cbd get adress Configuration file adress e g YANM alllnOneWMalllnOne xls get adress Result file destination e g Y ANM_alllnOne Result bt get adress Start verify b D BEEN Fig 8 User interface start screen 66 Before a Network management analysis can be done the program needs to know the addresses to the INCA log file configuration file and result file Fig 9 contains an example of a correct configuration Network Management Analysis CAN log adress e g YANM alllnOneXCAN in 14 dxl get adress Configuration file adress e g YANM alllnOneMalllnOne xls get adress Result file destination e g Y4NM alllnOneYsesult txt get adress Start verify Fig 9 Example of a correct configured GUI When all inputs have been done just click the start verify button to start the verification If everything went as intended the entry box in the GUI now should contain a simple text log see Fig 10 67 Network Management Analysis OBS CAN log
67. ndy when analyzing what lies behind an error See Fig 9 for an example of a detailed error log for the difference analyze 60 Ness REESE F G T H AvailCrankShaftTrqMin CAN Monitorir BRAKE PEDAL PRESSED CAN Monitc CC Active CAN Monitoring 1 Ec B BrakePedalActive Showing all errors 74 errors in total 10 on pos 17 2ts small der 0 00 0 00 10 on pos 1721s small der 0 00 0 00 c AvailableCrankShaftTrqMin Showing all errors 0 errors in total 10 on pos 17 225 small der 10 on pos 17 225 small der 10 on pos 17 225 small der 10 on pos 17 225 small der 1 0 on pos 17 225 small d 10 on pos 17 225 small der 10 on pos 17 23s small der 10 on pos 17 23s small der 10 on pos 17 245 small der 10 on pos 17 245 small d 10 on pos 17 245 small der 10 on pos 54 50s small der 0 00 0 00 VcDe_B_CCActive Showing all errors 0 errors in total 1 CCMode CAN Monitoring 1 Vc D CCMode Showing all errors 0 errors in total M 4 E NX Diffintegration Errors Difference Errors MinMax Errors Z result Fig 9 Part of a difference errors log J CCOverridden CAN Monitoring 1 VcDe B CCOverridden Showing all errors 0 errors in total v lt arl 61 3 Network management verification user ma
68. neutral format Python is therefore a good choice when the need of platform independency is big The python code will neither have to be rewritten to implement it on another platform than it originally was supposed to run on 2 2 5 Internet developing The combination of Pythons high level module support and RAD Rapid Application Development power results in an enormous easy accessible toolkit and makes it ideal for web applications where often speedy development is of crucial importance Python support among others libraries for parsing and handle XML HTML and CGI scripts Also protocols like POP3 IMAP and others are supported 2 2 6 Database programming Python is glancing with good support and module libraries also for database programming Python have interfaces for all of the commonly used databases such as mySQL Apache and Oracle The good text processing tools in Python often makes it to a better summary and report tool than the database built in interface 2 3 Why Python In automatic testing at VOLVO 2 3 1 PowerTrain test automation PTTA A system for automatic verification of control unit functions is under development at Volvo Car Company called PTTA and is written in Python The system is connected with the HIL Hardware In the Loop simulation environment The HIL system can simulate the dynamics of a whole vehicle or just chosen parts Through PTTA the user can start the HIL simulation with different initial settings de
69. nfigurations and settings It will neither be time sufficient implement everything Another problem that may occur is slow performance and allocation of all available RAM when using big log files e g many samples and or parameters in combination with many verification parameters 54 2 3 CANinterface_LIB module CANinterface_LIB py is the home for all implemented functions that are callable through the user interface Table 1 shows the containing functions Table 1 Function declaration for CANinterface LIB py Function Description readFromFile Reads the CAN file readSettingsFromExcel Reads the configuration file through COM interface findCanColumn Finds the right CAN file column due to the required parameters in the configuration file getColumnLin Extract a column in the CAN file due to the parameters in the configuration file Uses a first order hold algorithm to interpolate empty samples syncParam Sync two measurement vectors uTest Contains the CAN interface testing algorithm executeConfig Executes the CAN interface verification resultToExcelWriter Write the CAN interface verification result to a Microsoft Excel file x s through the COM interface 2 4 Configuration file The CAN interface configuration file must be an Excel file xls and contain one or more sheets For a configuration file example see Fig 2 The file provides the program with user defined test settings such as processing parameters
70. nnn ener nnne nnne 40 5 3 3 2 Power mode Settings risa enamel ema eei D eoo Bt fee ts 41 K S1enal Settings x T eee tau Dae tis 42 5 3 3 4 Settings for Special tests 3 omite A ee 42 5 3 3 5 Stand alone User interface eie Aene eee b irati el ete et dits 42 x34 Result Ele Ra cotto no Afi Meester M P 42 5 334 T General NM emots i o ione E 43 53 4 2 Specific NM verification nonien totalem tubi eiut nts 43 9 39 DC 43 5 3 5 1 Program functionality seed erii e ee e ete ree eee dede 43 5 3 5 2 Known problems and bugs sss sese 44 5 3 6 Conclusion id 44 5 3 7 F ture work uude ede E Pe P t e uei eerie ete reste vede 44 6 Discussion and Conclusion iden eene deed recie iei tese ince e Pe ede decree edenda 45 6 1 Program functionality and useability sss ee eee eee 45 6 2 Time profits eade hr RR ERR HEC I EN REG de RE TE Oe e t OT UE ERR ERE 45 6 3 Problemsiand pitfalls nee mete ie ee e Te E DH a Ee Re e acess deidad 46 6 4 The importance of satisfying specifications enne nnns 46 7 Fut re ARA er etie E A E E NAO 46 SBI MO STAPH eost A M rw e INS Be mtem E T A A A 47 O oec uc I dU de EM dte M a es M ed Le nr s 48 1 State machine verification user manual enne ennt 48 ARA eee de eie ettet e nete e ede tee 48 1 2 Program module OMM LIB pai dde 48 1 2 V OVETV T ee ee eee 48 1 3 Analyze classes eerte O 49 1 3 1 Basic Analyze daa 49 1 3 2 Time Analyze esit E 49
71. ntroller Area Network versions 3 Nomenclature Standard Max signal rate Identifier Low speed CAN ISO 11519 125 kbps 11 bit CAN 2 0A ISO 11989 1993 1 Mbps 11 bit CAN 2 0B ISO 11989 1995 1 Mbps 29 bit 4 2 Data transmiss ion The protocol does not us addresses to send a message to a specific node A message identifier is used instead which allows all nodes who want the information to read on bus Every node consists of a masking system that masks the identifier all the time if the received identifier matches the mask the transmitted data will be stored The identifier consists of either 11 or 29 bits depending on the CAN version When a node wants to transmit it has to wait until the bus is free undependable of priority If two nodes wants to send at the same time they will both start to send it s frame which always starts with the identifier Both nodes sends until it has been investigated which frame has the lowest identifier The node with the higher identifier then stop to transmit a lower identifier has therefore priority over a higher one For an example see Fig 1 ID s to send Node1 101000 0T 0 Node2 1 01000 U 1 0 Node3 101110 1010 Arbitration Node1 1 0 1 0 o oj1lo x Node2 1lol1 0 o o 1 o 0 110 Node 3 10 i s 70 Fig 1 Arbitration in this example Node 2 has the lowest identifier and will continue to send the remaining frame
72. nual 3 1 Introduction and program overview The program is written in the interpreting language Python and is used for network management NM verification The intention is to change from manually NM verification to scripted algorithms and analysis tools The program needs an Inca measurement log file as input Remark that the file must be saved in ASCII dxl format The analysis tools can be used for both TCM and ECM network management verification as long as it follows the CAN NETWORK MANAGEMENT 31812306 standard Fig 1 is a brief overview of the program s execution order The program itself contains following parts do Read CAN log do Read Conf File do Read PM File Statel Python module NM_LIB py NMtransition configuration as sheet in for example NMconfiguration xls Signals configuration as sheet in for example NMconfiguration xls Power mode settings as sheet in for example NMconfiguration xls Stand alone user interface GUI py Result file for example result xls State3 do NM analysis do Append result log State4 dojClose result log State2 do Fetch signal vectors Fig 1 UML flowing chart for the Network management verification program 3 2 Program description 3 2 1 The module NM LIB py NM LIB py is the home for all implemented functions that are callable through the user interface Table 1 show all functions in NM LIB py Table 1 Function overview for NM LIB py Functi
73. on Description CanFileReader alllnOneMatrixReader conditionMatrixReader pmReader findCanColumn getPointedCanVector getPointedCanMatrix pCanMatrixVerification getStatelnTime getLastValue appendLog Reads the CAN file Reads the first head sheet in the configuration file Reads the Signal sheet in configuration file Reads the power mode sheet in configuration file Finds the right CAN file column due to the required parameters in the parameter file Extract a column in the CAN file due to the parameters in the parameter file Uses a zero order hold algorithm to interpolate empty samples Merges the extracted columns from getPointedCan Vector Verifying the network management Extract the network management state for a given Extract the last network management state in the Can log Adds a text string to the result log 62 3 2 2 Configuration file 3 2 2 1 Overview The NM configuration file must be a Microsoft Excel file xls The first sheet should have same appearance as in Fig 2 Fig 2 Network management configuration file 3 2 2 2 NM state transitions The file constitutes of a 2 dimensional matrix with the NM states on each axis The matrix covers all possible NM state shifting the left most column contains from states and the first row to states As an example Fig 3 shows which cell that holds the NM transition criterions from
74. on input Since the program will be constructed in a way that provides good support and possibilities for future extensions a flexible configuration method is necessary 3 1 3 1 Basic Analyze configuration The basic configuration will be a 2 dimensional matrix with the first column and also the first row containing the state names according to the states of the state machine It will work as a jump matrix and covers all possible state transitions The cells of the matrix constitute either of a X which means not allowed transitions under all circumstances or a T directly followed by a number i e T2 which means that it follows the transtion condition specified below the transition matrix as T2 transition condition 2 The basic configuration sheet will also contain a table with all transiton conditions very likely table 3 1 In fact the basic configuration is just another representation for a fully configurationally state machine like the one in Fig 3 1 3 1 3 2 Time Analyze configuration The program will as stated above be provided with the possibility to extend the analyze However it will come with a plug in module allready with thr program release namely a module for analyzing the time in each state It will be possible to set min and max time for each state through a new Excel sheet in the configuration file 3 1 3 3 Signal configuration In addition to the basic analyze configuration the Excel file must also contain what pa
75. ontroller Module and Transmission Controller Module Another problem that may occur is slow performance when using large log files e g many samples and or parameters 24 5 Result The finished verification programs are described how it is constructed both in an overview perspective but also on detail level in this chapter There are also examples of verification results 5 1 Result State Machine Verification 5 1 1 Result overview The state machine verification program contains following parts e Python module OMM LIB py e Template for configuration file e Result presentation in form of automatically generated Excel files Fig 5 1 is an overview of the program structure represented as an UML class chart According to the class chart the program contains classes for handling of input result and analyzes But also a control class that instantiate the other classes and execute class functions It is possible to pick and choose what type of analyze classes to use for the verification It is also possible to create own analyze classes for inceased flexibility Fig 5 2 is a simplified overview of the program execution order represented in UML format operation NWmanagement measurementAddress configuration ddress analyzeMethods resultAddress ExitHandler inputHandler getAnalyzeMethods analyzeMethods measurementAddress configurationAddress 1 1 1 getMeasurement mea
76. oretical Overview The network management specifies in what modes a node can be running But also how and when transitions between different modes or states are allowed to be done According to CAN NETWORK MANAGEMENT 31812308 specification the states in Table 3 2 can be used when creating the network management Remark that the network management implementation must not contain all states Table 3 2 Network management states according to CAN NETWORK MANAGEMENT 31812308 State State numbering Reserved 0x00 Off 0x01 Start up 0x02 Communication Software init 0x03 Operation 0x04 Buss Off 0x05 Transmission Disconnected 0x06 Silent 0x07 Wake up Network 0x08 Wake up pending 0x09 Expulsion 0x0A Isolated 0x0B Expulsion Silent 0x0C Expulsion Diagnose 0x0D Bus Off Wait After run OxOE CAN controller Init Initialization OxOF Operation After run 0x10 Expulsion After run 0x11 Reserved 0x12 Reserved 0x13 Stopped 0x14 3 3 3 Required states and modes base flow CAN NETWORK MANAGEMENT 31812308 also specify a base flow with required states and transitions see Fig 3 2 The dotted lines are optional transitions However remark that the automated NM verification program will not demand network management based on the flowing chart in Fig 3 2 On the other hand it can not contain any other states than in Table 3 2 10 15 m a e E Stopped 11 13 r E x Off y j mE RR j Disconnect m 22
77. pending on the test The automatic test system also configures and starts the CAN logger Inca The last part in the automatic test chain is verification of the produced Inca log which is the main focus for this report 2 3 2 Reasons for using Python for PTTA There are several reasons why the automatic test system PTTA is written in Python The main causes are e The HIL system is delivered with a Python API for controlling the simulator e Developing in a scripted language takes often less time than in compiling dittos Python is the most common script language e The range of Python libraries is huge In addition all existing C libraries can be compiled to Python libraries And the range of C libraries is almost infinite e Program modules that require great performance or control can be developed in C and compiled as Python modules 3 Scripts for automatic verification and result presentation In this chapter theories for three different kinds of automated verifications are introduced namely verification of State Machines CAN Interfaces and Network Management 3 1 State machine verification Theory 3 1 1 Introduction The controller units of a car contain several types of state machines and are used to track and announce the state of a whole controller unit a single function or something else It s important that the state machines work in a correct way regardless external conditions A dysfunctional state machine can in wo
78. ping of new analyze classes will probably be required for a total verification future state machines 5 1 6 Future work e Developing new analyze classes to meet up with the verification requirements of upcoming state machines e Create configuration files for more state machines e Improve GUI to simplify for the user 32 5 2 Result CAN Interface Verification 5 2 1 Result overview The finished CAN interface verification program contains following parts Python library CANinterface_LIB py Configuration file for example CANconfiguration xls Mapping tables for example mapping sheet in CANconfiguration xls Stand alone user interface GUI py Result file for example result xls The program starts with reading the CAN log and configuration file It will then start to fetch pairs of parameter names to compare from the configuration file The parameters corresponding measurement vectors are fetched from the CAN log and the signal and verification processes starts The result is stored in a program variable This procedure repeats until all parameters are fetched from the configuration file and the result is written to the result log See Fig 5 9 for an overview of the program execution order dojRead CAN log do Read Conf file State4 do Signal analysis do Save analysis result State2 State3 all param fetched CallEvent1 State5 dojCreate log file log file do Fetch parameters to tes
79. r of bytes of Data 0 8 bytes Data field 0 8 bytes Data to be transmitted CRS 15 Cyclic Redundancy Check a kind of checksum CRS delimiter 1 Must be recessive 1 ACK slot 1 Transmitter sends recessive 1 and any receiver can assert dominant 0 ACK delimiter 1 Must be recessive 1 End of frame EOF 7 Must be recessive 1 72 Table 3 Extended frame format 3 Field name Length bits Purpose Start of frame 1 Denotes the start of the frame Identifier A 11 First part of the data identifier Substitute Remote Request 1 Must be recessive 1 Optional SRR Identifier Extension bit IDE 1 Must be recessive 1 Identifier B 18 Second part of the data identifier Remote Transmission Request 1 Must be dominant 0 RTR Reserved bits rO r1 2 Reserved bits Data Length Code DLC 4 Number of bytes of Data 0 8 bytes Data field 0 8 bytes Data to be transmitted CRS 15 Cyclic Redundancy Check a kind of checksum CRS delimiter 1 Must be recessive 1 ACK slot 1 Transmitter sends recessive 1 and any receiver can assert dominant 0 ACK delimiter 1 Must be recessive 1 End of frame EOF 7 Must be recessive 1 4 4 2 Remote frame In general there are most of the times no need for a remote frame the nodes are transmitting new data without being requested first Anyway sometimes it can be necessary for a node to request data from another specific node and will then use a remote frame
80. r2 will be done first when the scaling has been done and the offset is added If either or both of the parameters not fulfill the min max criterions a notation will be done in the result file 2 4 5 Difference The program contains an algorithm that compares Parameterl to Parameter2 The seventh and tenth columns in the CAN configuration file contain the maximum values tolerances for the difference without declare a verification error in the result file The seventh column contains the maximum allowed difference when the signal derivative is low and the tenth column maximum value when the derivative is big The break point between high and low derivative can be configured in column ninth see 2 4 7 2 4 6 IntError One of the program algorithms divides the parameter vectors in 1 second interval And then integrates the difference between Parameterl and Parameter2 over each of the interval If the integrated difference exceeds the IntError in column eight or eleven a notation will be done in the result log The eight column contains the maximum allowed IntError when the signal derivative is low respectively the eleventh column when the signal derivative is big 2 4 7 Derivative breaking point The value when the derivative changes from low to high is configured in column nine 56 2 4 8 Mapping The twelfth and last column in the configuration file contains sheet names to mapping tables for more information see 2 5 If Parameter2 doesn t nee
81. rame edu ere ea cee RR GE PRSE EV T HEU e EE do HE Is E dude 72 4 4 2 Remote frame i ost re e AA 73 4 43 Error frame 2 cde eR RE Fe HR e UTERE Goss e e HR QU Pe UR Edo HR dE duae 73 4 4 4 Overload frame dae 73 1 Introduction The car industries of today have to develop test and introduce new models in rapid speed It s not just to keep up the pace but also increase it all the time The company that has least delay between the drawing board and the customer has a great advantage To provide the market with cars whose design not being outmoded for as long time as possible are really invaluable The customer does not only demand a nice design though they also ask for good functionality low price environmentally friendly low fuel consumption and a bunch of other things To fulfill the customer demand all instances of the company not only have to do their best but also use the sharpest tools possible The verification of product functionalities is a very important link in the development chain and faster verification methods leads of course to a more in depth verification analysis and or a shorter time plan A more in depth verification out sources less functional testing on the customer and saves both resources for calling back products for updates and the customers temper and trusting The worst case scenario is when a car has to be called back for serious safety problems which also have happened for many car companies more than once
82. rameters to extract from the log file especially how the state parameter corresponds to the state names in the configuration file 3 1 4 Verification methods The verification process will check if the intern state parameter follows the user specifications in the configuration file The verification algorithms will cover following sources of error Not allowed transition Transition criterions not fullfilled To short time in state To limit in state exceeded In other words the python program verifies that the state machine implementation works as it was intended but not that the implementation itself is correctly specified 3 2 CAN Interface verification Theory 3 2 1 Introduction When connecting nodes for example different types of control units with a CAN bus it is of biggest importance that the node to bus interfaces works appropriate The intern node parameter must under all conditions have the right coupling to the corresponding extern CAN bus parameter That means the set of intern parameters must be compared with the corresponding CAN bus parameters during several types of operation conditions A mismatch can cause many types of problems everything from wrong outdoor temperature in the display window to a dysfunctional fuel injection 3 2 2 Theoretical overview The CAN interface is routing data between the controller unit and Controller Area Network The verification strategy is to sample internal controller unit paramet
83. ransition can t be done It can for example be from or to a non used state in a specific implementation In Fig 5 17 the transition from or to the Start up state are marked with an x because that NM 40 state isn t used in the example implementation the same goes for Reserved and a number of other NM states If the transition criterion contains a text string like the red marked one in Fig 5 18 the analysis will use that string as input The text string contents with descriptions are listed in Table 5 5 In fact the text strings follows the Python notation and are therefore ideally as program input Table 5 5 NM state transition criterions Variabel name Description AJ Stands for Allowed Jump Equal to 7 means allowed transition Equal to 0 means not allowed transition JC Stands for Jump Criterions Contains a list with states which must have been entered before transition If no criterions the list will only contain the single value 1 JT Stands for Jump Time Contains the maximum time for the transition to be done 5 3 3 2 Power mode settings The power mode settings are done in the PoweMode sheet of the configuration file It contains the allowed power modes for each network management state Fig 5 19 is an example for how the setting file should look like NM PM Settings State Allowed powermode Reserved PM 2 3 4 5 6 Off PM 2 3 4 5 6 Start up PM 2 3 4 5 6 Communication Software Init PM 2 3 4 5 6
84. rst case lock down a function node or even the whole car Careful and comprehensive verifications are therefore needed to ensure the functionality 3 1 2 Theoretical overview The state machines in a car network are used for track and announce the states of whole controller units a single function or something else as described in 1 1 The state machine contains of a countable number of states usually 5 25 states Only one state can be active at the same time The transitions between different states are controlled by transition criterions The transition criterions between two states are often one or more logical conditions Fig 3 1 displays an example of a state machine Table 3 1 contain the corresponding transition criterions for state machine in Fig 3 1 a 4 Stalle d Fig 3 1 Example of a state machine F Table 3 1 Transition conditions for the state machine in Fig 3 1 Transition Name Condition Tl ECM initialized P1X WakeUp KL15 HW P2X EUCD WakeUp HW or K115 HW T2 Start cranking Manual Cranking StartCrankManuel INT i e KL 50 HW and not Startblocking INT Automatic Cranking StartCrankAutomatic INT i e when cranking conditions are fullfilled see ref Error Reference source not found T3 Started a n gt n start and t gt t start time b T T start torque Condition a or a b is Engine and Supplier dependent This cond
85. s Signals configuration as sheet in for example NMconfiguration xls Power mode settings as sheet in for example NMconfiguration xls Stand alone user interface GUL py Result file for example result xls Fig 5 16 is a shortly description of the program functionality represented in an UML state chart diagram According to state chart diagram the program starts with reading the Network management log and configuration file It will then fetch the needed parameter or signal vectors from the CAN log Statel do Read CAN log do Read Conf file do Read PM file State3 State4 do NM analysis do Close result log do Append result log Fig 5 16 UML state chart diagram of the Network Management verification program State2 dojFetch signal vectors 5 3 2 Program module The program module NM_LIB py contains all functions that are callable through PTTA or the stand alone GUI The function declaration can be found in Table 5 4 Table 5 4 Function declaration for NM_LIB py Function Description CanFileReader Reads the CAN file alllnOneMatrixReader Reads the first NMtransition sheet in the configuration file conditionMatrixReader Reads the Signal sheet in configuration file pmReader Reads the power mode sheet in configuration file findCanColumn Finds the right CAN file column due to the required parameters in the parameter file getPointedCanVector Extract a column in the CAN file due
86. s E_OFWhIRoL D 3 0 05 2000 02 0 5 vabi RR_WHEEL_SPOACAN Manitaringl Bs i WNIRER o 250 5 5 2000 5 5 naAdress ABS_MALFNIOAN ing Bs_E_OFWhIRGR D 3 03 05 2000 o 05 vabi Parameterl Parameter2 Maz Difference IntError Yer result 4 PEDAL POSYCAN Menitering t Es ILAccPodalPur ek sk E E 44 BAROMETRIC_PRESSURE CAN Manitarin lt AmbiontProsrure sk fok E sk 50 AmbientTempYCAN Manit Es_Te_AmbTemp sk fok ok sk 51 AmbientTompOFACAN Manitaring s AmbTomp F 52 rank Shaft TrqMaxtCAN Manit bleCrankShaftTrqMax sh ok 232onpur 15 33r biq dor on par 18 04 53 rank ShaftTraMinACAN Mani Ibl CrankShaftTraMin ok ek fok ok 54 BRAKE_PEDAL_PRESSEDICAN Manitorin Es_E_BrakoPodal ictivo sh ok LT 17 2 rmall der ok 55 OCActive CAN Manitaring t VeDo E CCActive ok ok ek ok 56 CCMadetCAN Manitaring 1 C Mode ok ok ok ST CCOverriddenACAN Maritori VeDe_E_CCOverriddon ok jek ok ok 58 COSerSpeodNOAN M VeDo v COSetSpood ok lok ok ok 54 CCTracFarceReghCAN Manitaring t s CoTracForceRog ok lok ok ok 60 CrankShafeTeq CAN Manitaring t Ec Tq EnginoTarque ok ok 195 0 an par 22 04 rmall der on par 59 12 G1 CrankShafeTeqQFICAN Manitarin EngineTarquo 8 sk ok 30 0onpar 0 02r rmalldor on par 17 04 DriverCrankShaftTrqFieg CAN 195 0 an par 22 02r rmallder on par 22 01 43 ENG_COOLANT_TEMPACAN Manitari sk lok ok sk 4 Comments
87. s care of the whole chain from simulator configuration to log generation and verification 53 2 CAN interface verification user manual 2 1 Program overview The program is written in the interpreting language Python and used for CAN interface verification The intention is to change from manually CAN interface verification to scripted algorithms and analysis tools The program needs an Inca measurement log as input Remark that the file must be saved in ASCII dxl format This analysis tool can be used for both TCM and ECM CAN interface verification Fig l is a brief overview of the program s execution order The program itself contains the following parts Python module CANinterface_LIB py Configuration file for example CANconfiguration txt Mapping tables for example mapping sheet Stand alone user interface GUI py Result file for example result xls dojRead CAN log dojRead Conf File State2 dojFetch parameters to test State4 dojSignal analysis do Save analysis result do Fetch signal vectors all param Fetched CallEvent1 State5 9 do Create log file Fig 1 UML flowing chart for the CAN interface verification algorithm 2 2 Delimitations It will hopefully be few delimitations but there will always be test settings of non standard type the program can t handle The main reason not cover every possible test case is to hold down the complexity in the from user demanded co
88. saved as a new sheet with the name Signals in the configuration file It contains the parameter links between the Can log and the network management verification program Fig 6 shows how the parameter settings file should look like IM sign Sel tna Type of parameter Parameter name Time time NM state diag_NW_States CCP 1 PM keyPos or likely PowerMode Fig 6 Example of a parameter settings file 3 2 4 Power Mode settings file The power mode settings file should be saved as a new sheet with the name PowerMode in the configuration file It contains the allowed power modes for each network management state Fig 7 shows how the power mode settings file should look like State Allowed powermode Reserved PM 2 3 4 5 6 Off PM 2 3 4 5 6 Start up PM 2 3 4 5 6 Communication Software Init PM 2 3 4 5 6 Operation PM 2 3 4 5 6 7 Bus Off PM 2 3 4 5 6 Transmission Disconnect PM 2 3 4 5 6 Silent PM 2 3 4 5 6 Wake up Network PM 2 3 4 5 6 Wake up Pending PM 2 3 4 5 6 Expulsion PM 2 3 4 5 6 Isolated PM 2 3 4 5 6 65 Expulsion Silent PM 2 3 4 5 6 Expulsion Diagnose PM 2 3 4 5 6 Bus Off Wait After run PM 2 3 4 5 6 Can Controller Init Initialization PM 2 3 4 5 6 Operation After run PM 2 3 4 5 6 Expulsion After run PM 2 3 4 5 6 Reserved PM 2 3 4 5 6 Reserved PM 2 3 4 5 6 Stopped PM 2 3 4 5 6 Fig 7 Example of a power mode settings file The State column contains each NM state The A
89. sentation A result file is created after a successful verification process The file is in xls format and created through Microsoft Windows COM Interface First of all the file contains the verification result but also useful additional information for allocating errors and bugs The result presentation are not equal for the different kinds of verification methods 4 2 State Machine program 4 2 1 Background The state machines are today verified by manually change and manipulate inject errors etc the environment and either in real time or via a log file assess if the states are correct in respect to the current environment Both the real time view and logging functionality is managed by a program called Inca It s possible to log both node intern parameters and CAN bus parameters An Inca log file can be saved in either a dat format for process and analyze in MDA an analyze tool for Inca log files or in ASCII format for analyze in a text editor The setup for a state machine verification can be either a development car or a computer based simulation environment with possibility to read node parameters 22 4 2 2 Purpose and aims The manually state machine verification takes time and the demanded time for verification will incease along with upscaling of the cars electronic network Verification of growing electronic networks can be handled in at least three different ways Recruite more people in the same speed as th
90. surementAddress getConfiguration configurationAddress U IN basicAnalyze I5Dspecal c Qh le P SSS startAnalyze startAnalyze startAnalyze getConfiguration getConfiguration getConfiguration resultHandler resultHandler resultHandler G TimeAnalyze Fig 5 1 UML class chart diagram for state machine verification program 25 pre Analyze Analyze do Instantiate Analyze classes dojget analyze configuration do Start analyze do Write analyze to file M d Initialization do Instantiate InputHandler do Instantiate ExitHandler Le Handle inputs do Get input configurations do Get and parse Inca measurement Close operations do Close all open data streams O A Fig 5 2 State flow for state machine verification program 5 1 2 Program module OMM_LIB py The program module OMM_LIB py contain all code for verification of state machines The code is splitted into four categories e Input handling e Exit handling e Controller e Analyze verification handling See Fig 5 1 for the UML description 5 1 2 1 Class InputHandler The class InputHandler contain functionality to process and extract data from an Inca log file Table 5 1 describes the functions of InputHandler Table 5 1 Function declaration for class InputHandler Function Description getMeasurement Extracts the information from an Inca log file and sav
91. t via an cross language interface to Python The aims for the Python development and rule of thumbs for a Python programmer are summed up by Tim Peters in the following way The Zen of Python Beautiful is better than ugly Explicit is better than implicit Simple is better than complex Complex is better than complicated Flat is better than nested Sparse is better than dense Readability counts Special cases aren t special enough to break the rules Although practicality beats purity Errors should never pass silently Unless explicitly silenced In the face of ambiguity refuse the temptation to guess There should be one and preferably only one obvious way to do it Although that way may not be obvious at first unless you re Dutch Now is better than never Although never is often better than right now If the implementation is hard to explain it s a bad idea If the implementation is easy to explain it may be a good idea 2 2 Why Python In general Python can handle most kinds of programming issues fairly well and isn t restricted for some special kinds of development Within every project where rapid development scalability and flexibility are of importance Python is a good choice 2 2 1 Mathematics Python is an excellent tool for mathematical processing since it supports NumPy an extension which provides interfaces to many mathematics libraries The NumPy extension is written in C and as a result
92. t cee au A woes eid es d i e tee ieee 32 5 2 Result CAN Interface Verification cccccccccecccccecsssccceesscceceesceceessececeesaeeccsessececnsseeceeseeecesaseesenseeeeeens 33 5 2 Result overview ao csc S ue Ree aoe hc hte cee ded ioter aetate dede c aoe Bierce 33 5 2 2 Progra modules enrio o Ri dde i adest tte Meet o D A A IS 33 5 22 Configuration file xu see e tue ean ea DE e E Rete eto aote 33 3 2 6 4 Mapping tables ec ertet eO ne E Pe a e EU RE ve REOR SOR M VR ee amenities 34 5 2 3 Stand alone user intetface ie reset e a e UR ED RI orien ea UR EE e ies atin le 34 LADOS result nette ere TO ORE A EU RR TESEE I AR t E elas 34 5 2 4 TI ERI ERI RO TI EEI RO M E e e c a ee ee atin e cts 34 5 24 2 H 36 5 2 5 DISCUSSION inasnan E n a a EE Ra e E e Gg ree nee tope t et 37 5 2 5 Program functionality OPC e ERO T ED RR SEE HS TD Pa nee ete qu es 37 5 2 5 2 Known problems and DUES entre secco etie a e E e a D rae esee tag ne cs 37 5 2 6 CONC lUS avit e reU RERO NO UI QU ND ZTE dadig DR OT ts 38 52 7 Future WOrk nece EEUU RR INO OUR RUD DE RE S a c eee teet steep ot et 38 5 3 Result Network Management s ee a eee r a R D e Vere qr vere de cui et 39 5 3 l ResultiOverview ose duse ossi ue stetur Codicis e Tied suse bad E Meese ite Liat 39 5 3 2 Prograriqmodule iustae lalo A Dein pts 39 53 3 Con purdrlOns c5 ect A cisci i LM Rosi ur 40 5 3 3 1 Main configuration sheet eene enne ener enen ener
93. t dojFetch signal vectors Fig 5 9 UML state chart diagram of the verification program 5 2 2 Program module The program library CANinterface_LIB py contains all functions that are callable through PTTA or the stand alone GUI A functions declaration can be found in Table 5 3 Table 5 3 Function declaration for CANinterface LIB py Function Description readFromFile Reads the CAN file readSettingsFromExcel Reads the excel configuration file findCanColumn Finds the right CAN file column due to the required parameters in the configuration file getColumnLin Extract a column in the CAN file due to the parameters in the configuration file Uses a first order hold algorithm to interpolate empty samples syncParam Sync two measurement vectors uTest Contains the CAN interface testing algorithm executeConfig Executes the CAN interface verification resultToExcelWriter Write the CAN interface verification result to a Microsoft Excel file x s through the COM interface 5 2 2 Configuration file The appearance of the configuration file is more or most hard coded and very few deviations will be accepted For an example of a correct configuration file see Fig 5 10 Note that comments only can be done in the first column and must be proceeding by double number 33 signs Also remark that links to mapping files can t contain single backslashes due to Python notation All single backslashes must therefore
94. t seems like the interface to win32 COM in office 2007 slightly differs from the 2003 version in some points Hopefully and as far It s tested it will work as intended also on a platform with office 2007 5 2 6 Conclusion More or most all types of CAN interface parameters can be verified with this program module But the user must be aware of how to configure it for every single parameter pair to get a useful result That will however presumably not be a problem it will exclusively be configured and used by experienced CAN verifiers The functionality and performance will be best when using moderately big log files 5 50 Mb and the crashing risk will be minimal 5 2 7 Future work e Writing big parts of the module in a compiling language preferable C will speed up the execution time a bit However the program runs today sufficiently fast for the most applications e Extend the program flexibility and possibility to cover even more or maybe future types of CAN parameters The seamy side with extended flexibility will be a more unwieldy configuration file e Refine and optimize the code for faster execution and readability Not a big need but refining can always be done until end of days though 38 5 3 Result Network Management 5 3 1 Result overview The finished Network Management verification program contains following parts Python module NM_LIB py NMtransition configuration as sheet in for example NMconfiguration xl
95. then There are also good possibilities to extend the class library with new types of analyzes The existing analyze types are created after a generic implementation method and as long as the new analyze class follow this method it will be recognized and handled in a correct way by the verification tool A analyze class must contain the functions described in Table 3 Table 1 Function declaration for the Analyze classes Function Description getConfiguration Gets the necessary information from the configuration file startAnalyze Starts the analyze of the chosen parameter vectors extracted from the Inca log file resultHandler Organizes the result from the analyze and writes it to a new excel sheet Currently there are three created analyze classes e Basic Analyze e Time Analyze e Special Analyze for I5D engineState The basic and time analyze classes are general algorithms for state machine verification while the special analyze is tailor made for I5D engineState verification 1 3 1 Basic Analyze The basic analyze search for eligible state transitions in the log file in respect to transition conditions Many state transitions are never allowed i e the one not connected with an arrow in Fig 1 Errors will be presented in the result file 1 3 2 Time Analyze Calculates and verifies the time in each state Errors will be presented in the result file 49 1 4 Configuration file The Excel configuration file must
96. us on future work strongly connected to this thesis the following points are important to handle in the near future e Extend the library of configuration files for verification of more types of controller unit software The automated test system is designed to work with all available TCM and ECM software but it s only tested with a few ones because the lack of configuration files e Education of the testers in the new way of work Automated testing requires in many cases both different kind of competence and work approach than manual testing 46 8 Bibliography 1 2 3 4 5 M Lutz Programming Python O Reilly Media Inc 1996 CAN specification version 2 0 Robert Bosch GmbH 1991 Steve Corrigan Introduction to the Controller Area Network CAN Texas Instruments Incorporated 2003 Runar Frimansson Personal Communication September December 2008 Niklas Smith Personal Communication September December 2008 47 Appendix 1 1 State machine verification user manual 1 1 Introduction The program is written in the interpreting language Python and is used for verification of state machines See Fig l for an example of a state machine The intention is to change from manually state machine verification to scripted algorithms and analysis tools The program requires an Inca measurement log file as input Remark that the file must be saved in ASCII dxl format The verification program contain following parts
97. wn problems and bugs There are no recognized bugs as far as tested 5 3 6 Conclusion The program can be used for verifying the Network Management in most cases The seamy side is an ungainly configuration file The configuration file design can be improved in a plural ways Not much job is done there though because the state machine verification algorithms can in most cases be used also for verifying the Network Management state machine 5 3 7 Future work e Cleaner code and user interface are needed specially the configuration interface needs an update e Update the state machine verification code to fully include also network management This software will then be replaced with the state machine verification tool which is much more flexible 44 6 Discussion and Conclusion Profits and disadvantages for automated verification in general are discussed in this chapter Especially time profits and useability for automated verification methods are highlighted 6 1 Program functionality and useability The overall program functionality and particularly the usability for PowerTrain Test Automation PTTA is now with the log file verification and result presenting implemented improved And the step from development to commercial software has significantly decreased The PTTA system itself is a very flexible tool with big opportunities The program parts developed scripted and tested in this thesis are developed in the same sp
98. work Management program 4 4 1 Background The network management is verified today by manually studying the behavior during different types of operations and condition settings either in real time or via a log file Volvo Car Corporation uses Inca among others for logging the CAN and node activities The program provides the user with possibilities to choose what signals to analyze sample rate scaling and offset The log file can be saved either in Inca s own format dat or in a common ASCII txt representation 4 4 2 Purpose and aims As mention in the introduction part the time effort for testing network management manually are in many cases huge The aim will be to create a reliable automatic verification model with the purpose to considerable decrease the time demanded for the verification process The task will be done by implementing a new function library in the scripting language Python which is able to handle and analyze ASCII log files from Inca Another aim is after a successful development use the network management library in a simulation environment which automatically will generate an Inca log file for the chosen simulator settings 4 4 3 Delimitations The program will hopefully be quite flexible but with at least one big restriction The node must under all circumstances follow the specifications in CAN NETWORK MANAGEMENT 31812308 It is the official specification for network management in among others the Engine C
99. x x x x x x x x T Bes Off WaittAfter ren x Alsace x Mehr Be TE 7 m rE 7 P Ta i x x x AMEL AJetCe x x AJ tJC l x x 38 Can Controller InitiInitializal x Ades x Adet Csl x x Ads0 IC AJstCs x Adz0Cs x x 19 Operation After ran x Ad JC x Ade sf x x x ICs x x 53 AdeO JC l x x 20 Expulsion After ren x AdstIC x AJ 1JC AJz0 JCz ba ACL be ACL x x x Adz0 JCz AJ 0 JC x x AJ tJC AJsQJCz M JTzO AJsfJCs x x 21 Reserved x x x x x x x x x x x x x x x x x x x 22 Reserred x x x x x x x x x x x 23 Stopped x Aep x Ahir ued At JC AJet CsC x x x Aps AJ f Cl x x Alpa Aep AJsfJCs H JT 53 AJtCs x x Ada JC AJT 53 24 Las 26 a 28 Type of test Facit ONIOFF 23 Bus off BwOf OFF 30 Test2 Test2 ON 31 Teta Test3 ON 32 Expulzion Expulsion ON 33 Testa Tes OFF 34 Tests Tests ON 35 36 EJ 138 EJ 40 From To Reserved Off Start up Operation Bus Off Silent Wake up Network Communication Software Init Transmission Disconnect Rese Off TX cR 04 04 04 04 0X x x X X AJ 1 Jx x X AJ 1 Jx AJ 1 Jx x x x X x X x X X AJ 71 J AJ 70 JC A71 AJ 0 J x x x x x X AJ 1 J 4J 1 J0 A 71 AJ 0 J x AJ 0 J AJ 1 JC AJ 1 AJ 1 J x AJ 1 J AJ 1 JC AJ 1 AJ71 J x AJ 1 J AJ 0 JC AST AJ 71 J x x x x x x x X x x x Start up Comm Operati Bus CTransi Silent Fig 3 Part of NM configuration file head sheet NM state transition criterion from Operation to Off is red marked 63 3 2 2 3 NM state

Automatic verification of controller unit functions

Contents

Download Pdf Manuals

Related Search

Related Contents