CAN总线分析工具BUSMASTER

© Copyright 2011 Robert Bosch Engineering

and Business Solutions Limited

2 | BUSMASTER | TOC

Contents

Interface Details...............................................................................................................6Design Scope....................................................................................................................7Design Methodology......................................................................................................13Design Notations............................................................................................................14Design Considerations...................................................................................................15Design overview.............................................................................................................25Architecture Design.......................................................................................................26

DIL_Interface..................................................................................................................................26IDIL_CAN.......................................................................................................................................27

DIL_ES581..........................................................................................................................28DIL_BOA............................................................................................................................29DIL_Stub_CAN...................................................................................................................30

ConfigDialogDIL.............................................................................................................................31Bus Statistics....................................................................................................................................32Simulation Engine...........................................................................................................................34Project Configuration......................................................................................................................38Logger..............................................................................................................................................42Message Window............................................................................................................................46Filter.................................................................................................................................................48Session Replay.................................................................................................................................48Node Simulation..............................................................................................................................50Frame Transmission........................................................................................................................55Signal Watch Window.....................................................................................................................55Test Automation..............................................................................................................................57

Test Setup Editor Lib module..............................................................................................58Test Suite Editor and Executor Lib.....................................................................................59Test Setup Editor.................................................................................................................60

Automation Server Interface...........................................................................................................61

Interface Design.............................................................................................................63

User Interface..................................................................................................................................63Component Interface.......................................................................................................................63

Test Suite Editor and Executor Lib.....................................................................................63

Design Alternatives.......................................................................................................65Design Feasibility...........................................................................................................66Design Tools used..........................................................................................................67Additional Hardware and Software required............................................................68Test Strategy..................................................................................................................69References......................................................................................................................70

BUSMASTER | License Information | 3

License Information

This is a free document: you can redistribute it and/or modify it under the terms of the GNU Lesser GeneralPublic License as published by the Free Software Foundation, either version 3 of the License, or (at your option)any later version.

This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without eventhe implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNULesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this artifact. If not, see.

4 | BUSMASTER | Acknowledgement

Acknowledgement

The BUSMASTER application suite evoluted from its incipient stage of monolithic single bus - single controllerarchitecture towards the present stage of modular & reusable component based architecture, easily and seamlesslyextendable to support multiple vehicle buses, exhibiting a rich set of carefully crafted feature list. Reaching ofsuch a milestone was possible only by the valuable contributions from many dedicated and skilful professionalswho were involved at different cycles of the development process defining the trajectories of the product’s

evolution, translating many innovative ideas into reality. The contributors so far are Mrs. Jalaja K.V, Mr. AmiteshBharti, Mr. Amarnath Shastry, Mr. Ratnadip Choudhury, Mr. Pemmaiah B.D, Mr. Raja N, Mr. Rajesh Kumar R,Mr. Anish Kumar, Mr. Pradeep Kadoor, Mr. Arunkumar Karri and Mr. Venkatanarayana Makam.

This design document is the summation of all the relevant design documents, notes and an analysis report,

produced and refined throughout the development process, and hence is an integrated version prepared to roll outthe OSS version of BUSMASTER.

BUSMASTER | List of Abbreviations | 5

List of Abbreviations

Abbreviations, non-standard terms and acronyms that are used in this document are to be listed here.

APIBOACANDILFlexRayGUIHLDJ1939LINOODOSSRBEISEIUI

Application Programming InterfaceBasic Open ArchitectureController Area NetworkDriver Interface Library

A vehicle communication system developed bythe FlexRay consortiumGraphic User InterfaceHigh Level Design

A CAN based higher layer vehicle bus standardLocal Interconnect NetworkObject Oriented DesignOpen Source Software

Robert Bosch Engineering and BusinessSolutions Limited

Software Engineering InstituteUser Interface

6 | BUSMASTER | Interface Details

Interface Details

This document describes at length the various design aspects of BUSMASTER tool family which aims atsimultaneous support of any vehicle bus standard.

For obvious reason the design approach primarily harps on the principle of large-scale reuse and consequentlyis broadly inspired by product line model to leverage on this said aspect. The approach conforms to the SEI

definition of product line engineering which is “A set of systems sharing a common set of features that satisfy thespecific needs of a particular market segment or mission and thus are developed from a common set of core assetsin a prescribed way”. So outlining of the engineering activity may be presented by the following:

BUSMASTER | Design Scope | 7

Design Scope

The modules mostly have a one-to-one mapping with the feature set the application suite. The feature list againstthe implementing modules is tabulated below:

SI. No.12345Feature NameProjectconfiguration savingand retrievalInterface for a DILof a busCAN DIL ES581CAN DIL PEAKUSBCAN DIL BOAModule NameProjectConfiguration.dllDIL_Interface.dllCAN_ETAS_ES581.dllCAN_PEAK_USB.dllCAN_BOA.dllRemarkUsed tostore projectconfiguration datain a binary filewhich also canaccommodatemultiple projectinformation. Ifnecessary, ODBCsupport can alsobe brought in; thisis supported by itsdesign.DIL stands forDriver InterfaceLayer and is theinterface to the bus.This abstracts outthe driver detailsfrom the applicationthereby bringingin loose coupling.When the queryfor a particular businterface from theclient component toDIL_Interface.dllis successful, thislibrary rendersthe appropriateinterface.CAN DIL interfaceto ES581.xcontroller fromETAS GmbHCAN DIL interfaceto PCAN controllerfrom Peak GmbHInterface to BOAfrom ETAS whichis an abstraction toits CAN hardwareinterfaces. Thiscompletelydecouples the clientapplication fromthe underlyinghardware. | BUSMASTER | Design Scope

SI. No.678Feature NameCAN controllerconfigurationCAN bus simulationFilteringModule NameConfigDialogsDIL.dllCAN_STUB.dll &BusEmulation.exeFilter.dllRemarkImplementsthe controllerconfigurationGUI. This makesit possible forBUSMASTERapplication tocompletely getdecoupled fromthe underlyinghardware support.Addition of anew hardware /controller for a busmeans a updatingin DIL_.dll,ConfigDialogs.dlland introductionof _.dll.Commercial featurerelated files &routines will betaken off.The first one isCAN DIL interfaceto simulationengine. Secondone is also knownas simulationengine; this realizesa virtual bus inthe workstationmaking it possiblefor any instance ofBUSMASTER toact as a node andcommunicate viathis communicationchannel. By designthis should be ableto simulate any bushitherto known andunknown. Also,the same instanceof server can caterto any number ofbuses with anynumber of nodessimultaneously.Implements filteringconfigurationdialogues. Both acomposite aggregateand generic.Commercial featurerelated files &8SI. No.91011Feature NameNode programmingand simulation forCANLogging of framedataPlay back a sessionModule NameNodeSimEx.dllFrameProcessor.dllReplay.dllBUSMASTER | Design Scope | 9

Remarkroutines will betaken off.Realizes greaterpart of the nodeprogrammingfeatures.Accommodatesboth function editorand node executormodules. Functioneditor is generic andis configurable byits client on the flyto cater to variousbus interfacecharacteristics.Node executor -on the other handcontains individualbus specific slimsub-modules withmajority of commonmodules / classes.Is utilized to logmessages. Whenqueried, thisprovides interfaceto various submodules specific toindividual buses.Since loggingprocedure issame for any bus,save the protocolspecific frameinformation, theclasses all descendfrom a commonclass and employscommon workerthread function.This results insaving a lot ofimplementation andtesting effort. Forexample - addingJ1939 support took3.5 days of effortinstead of the usual2.5 weeks of effort,thereby saving 72%.Implements thereplay module,covering bothconfiguration andoperation aspects. | BUSMASTER | Design Scope

SI. No.121314151617Feature NameSignal watch - CANCAN Frametransmission - bothin mono shot andcyclic modesSignal graphCAN messagewindowTest AutomationDatabase editorModule NameRemarkTested so far onlyfor CAN.SignalWatch.dllImplements signalwatch windows.Dynamicallyconfigurable for anybus.TxWindow.dllImplementsmessagetransmissionconfiguration UIsand helper modules.Implemented so farfor CAN.SigGrphWnd.dll &CGCtrl.ocx1.Responsiblefor managingthe signal valuedisplay in thesignal graphactiveX control.Configurable forany bus and sothe bus-specificroutines areresponsibilitiesof the clientmodule.2.This is the signalgraph controlwhere selectedsignal valuesare displayed ascontinuous linediagrams.PSDI_CAN.dllA helper modulefor CAN messagewindow containingall the bus specificassociated routines.TestSetupEditorGUI.dll,TestSetupEditorLib.lib,1.This is the editorTestSuiteExecutorGUI.dllof a test setup&file.TestSuiteExecutorGUI.lib2.This is thehelper libraryexclusively fortest setup editor3.This definesa test suite,executes thesame and savesthe result in thedesired format.BUSMASTER.exeBUSMASTERapplication. Full10SI. No.1819202122232425Feature NameBus statisticsAutomation serverinterfaceLog file exportTrace windowMain GUI andcontroller &configuration forother modulesHelper libraries (notfeature)Helper libraries (notfeature)Helper libraries (notfeature)Module NameBUSMASTER.exeBUSMASTER.exeBUSMASTER.exeBUSMASTER.exeBUSMASTER.exeDataType.libUtils.libCommonClass.libBUSMASTER | Design Scope | 11

Remarkdecoupling is notyet fully achieved;this contains somegeneric classes,modules as well.Commercial featurerelated files &routines will betaken off.Same as aboveSame as aboveSame as aboveSame as aboveSame as aboveImplements the datatypes / structuresthat are widelyutilised by anymodule / componentof BUSMASTERtool family. Thiswas created withthe idea to solvethe greater partof the problem athand by properlydefining the datatype. Commercialfeature related files& routines will betaken off.Contains someutility services,both GUI and non-GUI, commonlysoughted afterby any module /component ofBUSMASTER toolfamily. Commercialfeature related files& routines will betaken off.Implements someutility classescommonly used.Commercial featurerelated files &routines will betaken off.12 | BUSMASTER | Design Scope

SI. No.26Feature NameWave patterngeneratorModule NameSignalGeneration.dll,BUSMASTER.exeRemarkThis generatessignals withvalues matchingcertain regularwave patternslike sinusoidal,triangular, spikeetc. For CAN thefirst two has beenimplemented.This design document addresses all the required different design aspects namely:1.2.3.4.5.

Component diagramState machine diagramSequence diagramClass diagram

Deployment diagram

So for every module the applicable design will be discussed on.

BUSMASTER | Design Methodology | 13

Design Methodology

Hybrid design methodology consisting of structured and object oriented has been used.

14 | BUSMASTER | Design Notations

Design Notations

••

For design, UML 2.0 notation is used

For class nomenclature, the RBEI/ECM coding guideline has been followed.

BUSMASTER | Design Considerations | 15

Design Considerations

Here some the design requirements which are to be followed while carrying out development activitiesare described concisely. The BUSMASTER application design & architecture specification, followingcontinuous associated improvement activities, evoluted from a vast monolithic architecture into a properly

harmonised ensemble of loosely coupled reusable and efficient modules & components. As a natural and obviousconsequence, certain patterns and structural approaches for development, albeit implicit, resulted. This documentaims at capturing those steps and implied procedures.The various aspects can be listed as:

1.Adequate loose coupling between UI and data: This application is GUI based for normal usage. However,usage as automation server is also possible.Towards this, a problem arises which is related to the complexity in harmonization of GUI with theapplication data (backend data).

The user modifies the application data through the GUI which is a coarse visual reflection of the data. Thehandler modifies the data as per the user’s choice and domain rules and then updates the GUI based on thehandler or function data.

It is often missed that GUI is only one of the ways to initiate application data modification activity.

Explicitness of the other one remains unconsidered most often. Therefore, the design and the very structuringof the sub modules & function list naturally don’t support this aspect. The result is obvious – whenever sucha need arises (e.g., exploitation of the feature from some other module while keeping the GUI on, automatedtesting etc), bugs with synchronization of GUI with the application data, unexpected crashes, duplication ofcodes etc creep in. This results in patch work, which further pervades into chaotic coding and many otherundesirable consequences.

A sample code is presented below. The use case deals with 5 controls and takes the services of 5 utility APIcalls from the application data manager library.

So long as we use the GUI to run this particular use case, things will proceed as expected, in the right

manner. However, when it is done through some other means instead, (e.g., from a tester module running theapplication in the server mode, running the use case from another sub module etc). Something unexpectedhappens most often. In case of the former, a crash in case the GUI code doesn’t always validate the propernessof the window or control handles or object pointers. In case of the later, either duplicate code and hencepossibility of the GUI not appropriately reflecting the application data state. Add with it the numerous GUIconditions.

16 | BUSMASTER | Design Considerations

Very defensive coding may solve the problem. Nevertheless – it should always be kept in mind that that ishard to practice and also this can make the code rather ugly and unreadable. Hence, a design solution may bethe most natural and therefore, best approach.// Data_Manager.cpp

RET_TYPE Function1_Exported(ARG_TYPE);RET_TYPE Function2_Exported(ARG_TYPE);RET_TYPE Function3_Exported(ARG_TYPE);RET_TYPE Function4_Exported(ARG_TYPE);RET_TYPE Function5_Exported(ARG_TYPE);// GUIClass.cpp

#include \"Data_Manager_extern.h\"

// Set of functions that operate on Control 1 upto 3void GUIClass::Modify_Control1(ARG_TYPE){

// Modify control1 according to ARG_TYPE}

void GUIClass::Modify_Control2(ARG_TYPE){

// Modify control1 according to ARG_TYPE}

void GUIClass::Modify_Control3(ARG_TYPE){

// Modify control1 according to ARG_TYPE}

void GUIClass::Handler(ARG_TYPE) // The handler implements the logic to realize

{ // the desired functionality.if (Function1_Exported(..) == SUCCESS){

Modify_Control3(..);

if (Function5_Exported(..) == SUCCESS){

if ( Function3_Exported(..) && Function2_Exported(..) ){

// Code to update control 4 Modify_Control2(..);}

if (Function4_Exported(..) == FAILURE){

Modify_Control1(..);}else{

// Code to update control 5 }}}}

The solution crafted is layering of responsibilities by introducing a two-way communication with the datasource. Any change in the back-end data can be indicated to the existing clients implemented either in eventnotification or call-back function. So the back-end data or the application data manager should have a well-defined interface. A typical use case can be realized by the execution of a few routines in some order, withadequate parameters.

BUSMASTER | Design Considerations | 17

The solution concept is inspired on the observer design pattern and the model-view-controller softwarearchitecture.

2.Abstract data channel: Usage of BUSMASTER falls under two distinct categories namely, bus monitoring& analysis, and node simulation. Undercurrent of the first one is “retrieve data and represent the same in thedesired fashion”. All the major functionalities like frame display, logging, data interpretation, signal watchand graph, replay etc have frame data processing as the kernel of their activities. That’s why it is of paramountimportance to make the data retrieval procedure efficient and simple. The below diagram depicts such aschema ~

18 | BUSMASTER | Design Considerations

This calls for an optimised design for the message buffer classes which also qualifies the necessary

performance criteria. Since frame data processing lies as the core of the activities, this issue is of paramountimportance and even an iota of improvement in this direction can significantly contribute is performanceelevation. The next point details on this.

3.Optimised data design: Reiterating the RS, this discussion continues with the disclaimer that no loss of framedata can’t be guaranteed. Only the possibility of data loss can be brought down with efficient design of thedata structure. In a non-real time system like Windows this can be achieved by using buffer(s) as temporaryplaceholder(s) of data as shown in the figure above. The controller in addition contains a buffer that providesthe first level of buffering whereas the application buffer is the last one. Hence we have an ensemble of twobuffers – one from the controller and the other from the application.

BUSMASTER | Design Considerations | 19

Hence the deciding factors can be the following:1.2.3.4.5.

Size of the controller bufferController buffer managementSize of the application bufferApplication buffer management

Retrieval process of frame data from the driver.

‘A’ and ‘B’ are out of the purview of our discussion on analysis and strategy.Optimum size calculation of the application buffer depends on the following factors ~

1.A.Current bit rate / throughput per second. It is finally the amount of data per second / millisecond thatmatters and hence the upper limit of total data at any moment.

2.B.Space management of each frame entry. Since the payload / data segment length of frames of buses likeFlexRay or J1939 varies within a known range, a buffer of maximum allocable size can cater to a frame ofany allowable length. In another approach, only the space of the actual size may be used – given we knowthe current bit rate. The former approach may be called method of fixed-size entry whereas the later onemay be termed as method of variable-size entry.Formulation for method of variable-size entry

Let rt bps be the data rate at any moment t. If T seconds is the total time for which the bus data are to beretained, then the total amount of space can be expressed as -S = # rt , where 1 <= t <= T.Assuming R be the average data rate,S = R * T

Let C be the controller buffer size and M be the application buffer size. Hence, the following inequality musthold good -R * T < C + M

Considering the bus to be FlexRay, for each channel,Rmax = 10 MbpsRmax = 10 * 2^17 bps

Counting both the channels, the total data rate is 10 * 218 Bps

Calculation of the optimized value of application buffer size depends on the realistic value of R and correctvalue of C.

Assuming maximum data rate and neglecting C, we find for FlexRay ~M > 2.5 * T MB

The payload segment of a frame varies from 0 up to 127 WORDs. Hence the above formula is useful whenthe buffer for a frame is not assumed to be of fixed size and hence follows the implementation.Similarly, for a CAN controller with a single channel -Rmax = 1 MbpsRmax = 2^17 Bps

Again assuming maximum data rate and neglecting C, we find for CAN ~M > 1^27 * T kB

Formulation for method of fixed-size entryThe first use case cited is for FlexRay bus.

If Fcurr is the size in bytes of the current frame, then

Fcurr = 8 + 2 * W, where 0 <= W <= 127 and W is the number of WORDs in the payload segment.

20 | BUSMASTER | Design Considerations

If N is the number of Fcurr frames, then the following equation will hold good,R * T = N * FcurrN = (R * T ) / (8 + 2 * W)

For evident reason, space for every entry is allocated to accommodate frame of maximum size i.e., Fmax =262 bytes.

Therefore, total amount of space needed is,M = N * Fmax

M = (R * T * 262) / (8 + 2 * W)

Assuming maximum data rate accounting both the channels,M = (2 * Rmax * T * 262) / (8 + 2 * W)M = (10 * 218 * T * 262) / (8 + 2 * W), in MBClearly, M and W are inversely proportional.

The following graph shows the amount of memory to be allocated for different payload segment length whenthe data rate is 10 Mb/s for each channel and the data need to be contained for a second.

Similarly, for CAN also the same calculation may be carried out in which both normal and extended framesare considered. Maximum baud rate is assumed and for each data length code value ranging between 0 and 8,the number of entries in fixed-size entry buffer is calculated out. The consolidated result is represented with aline diagram. Below is shown the application buffer size nuance chart:

BUSMASTER | Design Considerations | 21

DLCFramespersecond23831.27273201.9230817476.26667120.23529Memory(KB)558.72.61538409.6361.41177DLCFramespersecond1638414563.5555613107.211915.63636Memory(KB)384341.3333307.2279.2727DataRate1048576Duration1Staticsection(standardCAN)44Framelength192Staticsection(extendedCAN)Purpose01230123456713797.0526312483.0476211397.5652210485.76323.3684211292.5714286267.1304348245.756710922.6666710082.4619362.2857148738.133333256236.3077219.4286204.88Type9709.037037Field227.555555688192Length(Bits)[Max]1192Length(Bits)[Min]1BaseFrameFormatBaseFrameFormatStart-of-frameDenotesthe startof frametransmissionA(unique)identifierIdentifier1111 | BUSMASTER | Design Considerations

TypeBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatBaseFrameFormatFieldRemotetransmissionrequest(RTR)Identifierextensionbit (IDE)ReservedBit (r0)DataLengthCode(DLC)Data fieldCRCCRCDelimiterACK slotACKdelimiterLength(Bits)[Min]1114015111Length(Bits)[Max]111415111Purposefor thedataDominant(0) (seeRemoteFramebelow)Must bedominant(0)OptionalReservedbit (itmust beset todominant(0), butacceptedas eitherdominantorrecessive)Numberof bytes ofdata (0-8bytes)Data to betransmitted(lengthdictatedby DLCfield)CyclicRedundancyCheckMust berecessive(1)Transmittersendsrecessive(1) andanyreceivercanassert adominant(0)Must berecessive(1)22BUSMASTER | Design Considerations | 23

TypeBaseFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatFieldEnd-of-frame(EOF)Start-of-frameIdentifierASubstituteremoterequest(SRR)Identifierextensionbit (IDE)IdentifierBRemotetransmissionrequest(RTR)ReservedBit (r0, r1)DataLengthCode(DLC)Data fieldLength(Bits)[Min]711111181240Length(Bits)[Max]71111118124PurposeMust berecessive(1)Denotesthe startof frametransmissionFirst partof the(unique)identifierfor thedataMust berecessive(1)OptionalMust berecessive(1)OptionalSecondpart of the(unique)identifierfor thedataMust beDominant(0)Reservedbit (itmust beset todominant(0), butacceptedas eitherdominantorrecessive)Numberof bytes ofdata (0-8bytes)Data to betransmitted(lengthdictated24 | BUSMASTER | Design Considerations

TypeFieldLength(Bits)[Min]Length(Bits)[Max]Purposeby DLCfield)ExtendedFrameFormatExtendedFrameFormatExtendedFrameFormatCRC1515CyclicRedundancyCheckMust berecessive(1)Transmittersendsrecessive(1) andanyreceivercanassert adominant(0)Must berecessive(1)Must berecessive(1)CRCDelimiterACK slot1111ExtendedFrameFormatExtendedFrameFormatACKdelimiterEnd-of-frame(EOF)1177The relative advantages and disadvantages of the two methods are tabulated below:

Fixed-size entryResource usageVariable; payload lengthof the frame is thedeciding factor. Henceempirical data analysis isone of the means whichis not guaranteedEasier. There is no needto think on room for anentry.Variable-size entryFixed; only themaximum bit rate is thedeciding factor.Easiness ofimplementationQuite complex.Variable-size entry method guarantees the most optimum usage of memory and addressing of any situationand hence real sturdiness. On the other hand, fixed-size entry method has a better performance. However,the difference in performance is not of a crucial magnitude. Therefore, choice of method is subject to the busstandard. For example – for CAN method of fixed-size entry is used whereas for J1939 the other one is used.The application buffer class is the best agency to provide the information of buffer overrun. The ‘Write(…)’method can check if the slot to write the new frame data is free. A new method can be exposed or an event canbe fired to notify its client in case such occurrence. In fixed-size entry method it is also possible to keep countof the number of frames missed whereas in variable-size entry method it is not possible.

BUSMASTER | Design overview | 25

Design overview

The below diagram provides an overview of BUSMASTER application suite. This is a hybrid diagram combininginteraction, component, and deployment views. Discussion under the architecture design section is based on thisand the module list table.

26 | BUSMASTER | Architecture Design

Architecture Design

This section details about the individual logical entities covering the necessary views and interface details.

DIL_Interface

This module acts as the interfacing entity between the application and the expected DIL for the intended bus. Thisis the deliverer or interface manager of the DIL interface required by the application or the client. The procedurestarts with the client’s querying for the DIL and if it’s available, DIL_Interface returns the interface pointer(IDIL_) to the client. To get hold of a controller interface or even the simulation engine, a query must bemade using the interface pointer. The whole arrangement is presented by the below component diagram coveringsupport of CAN, J1939 and FlexRay with the support of a few controllers:

The calling sequence of query is illustrated by the following sequence diagram:

BUSMASTER | Architecture Design | 27

IDIL_CAN

This is the DIL interface of CAN. The class CDIL_CAN acts as the router, to maintain dynamic mapping

between the interface and the target DIL function of the intended controller. The below class diagram provides aglimpse on that procedure.

28 | BUSMASTER | Architecture Design

Support of any controller needs writing of a socket for the same. This is implemented as a DLL and obviously theexported functions have the same prototype with the of the other controllers.

DIL_ES581

This is the interface to ES581 interface. Below goes the interface description:

BUSMASTER | Architecture Design | 29

DIL_BOA

This is the interface to BOA interface. Below goes the interface description:

30 | BUSMASTER | Architecture Design

DIL_Stub_CAN

This is the interface to simulation engine interface. Below goes the interface description:

BUSMASTER | Architecture Design | 31

ConfigDialogDIL

An overview of this module highlighting upon its constitutional and runtime behaviour is shown below:

32 | BUSMASTER | Architecture Design

Bus Statistics

Like the other monitoring and analyzing modules, this Bus Statistics module implementation too follows the datachannel abstraction procedure as already explained. This means – it owns a data buffer and uses it to register tothe DIL as a data channel under the same client ID of its container – the application.

DIL ensures the buffer gets updated with the bus traffic. A worker thread maintained by bus statistics modulewaits for the notification event of the buffer and updates a set of bus statistics data parameters. The UI sub-module accesses the statistical data parameters at frequency according to the refresh rate set, and refreshes therequired controls accordingly. This is depicted by the following component diagram:

BUSMASTER | Architecture Design | 33

34 | BUSMASTER | Architecture Design

Below is provided the class diagram:

Simulation Engine

We start with a brief recapitulation on the overview of simulation engine.

BUSMASTER | Architecture Design | 35

Clearly, it a manifestation of inter process communication with an abstraction on the vehicle bus standard datatype. Communication among various instances of the application takes place through an out-of-proc server namedas SimENG. The server exposes an API set which a client may use to exploit its functionalities. The server keepsa list of all its clients. When a client calls “SendMessage”, the server adds this message entry into a circularbuffer. The message entry saves id of the sender in a parameter of it. SimENG maintains a worker thread whichgets activated when the circular buffer is non-empty. It then retrieves the current entry and runs through the clientlist. In case the present client is the sender, message status is kept as “Tx”, else the default setting is “Rx”. Thethread pumps the current message entry into the pipe and signals an event which is an auto-reset one. A threadinside the client process must wait for that. The waiting thread inside the client process then retrieves the messagefrom the pipe.

The following diagram shows the registration / unregistration activities of multiple clients in a macroscopic view.

36 | BUSMASTER | Architecture Design

The registration procedure is elaborated in details with the following diagram:

BUSMASTER | Architecture Design | 37

The below diagrams describe the process of frame transmission and dispatching:

38 | BUSMASTER | Architecture Design

Project Configuration

This module is implemented as a DLL which exports some functions for one or multiple project configurationdata retention in a file. The file is called the project configuration file. It’s a binary file.

Project data are logically organised to follow a schema alike to database. This means the entry point is a mastertable which is called ‘Project Table’ and lists the different project entries. So the primary key of each entry isthe project name. This means it is possible to work with configuration data of multiple projects. Each projectentry is parameterised with information like language code (ISO 639-3), time and date of last editing, applicationversion and the unique identifier of the application. Configuration data section of a project is maintained in anentity called section table. Each project has its own section table which is identified by the name of the project.A section table is the summation of section entries, which is defined by a section name, the section data pointerand the data length in bytes. Hence, a section is a quasi-unit of a configuration data. This view is depicted in thefollowing data model diagram:

BUSMASTER | Architecture Design | 39

The implementing components are carved based on the aforementioned data model and the interfacing aspect ofthe library with its client applications or components. A simple API set of exported functions is sufficient for theinterfacing requirement. Also, there must be avenues to use both file and database system (should the need ariseto realise this in future) for the archiving purpose. Hence, results the first object named as ‘Project ConfigurationInterface Manager’. Based of the current choice (file or database system), the path forks.

40 | BUSMASTER | Architecture Design

The object ‘Project Configuration Manager’ deals with the project list whereas the entity ‘Project Data’ managesindividual project data (the section list) and makes it possible to process section data through ‘Section Data’

object. The four entities are the cornerstones of the Project Configuration library. The component diagram showsthis arrangement with an outlining on the data and control flow.

BUSMASTER | Architecture Design | 41

The concrete implementation is described with the following class diagram. Again, theclass designing is directed by the data model schema and closely reflect the organizational

aspect.

42 | BUSMASTER | Architecture Design

The other supporting data types are presented

below.

Therefore, design of project configuration library again follows a hybrid design methodology, albeit wellrhythmized.

Logger

Data channel abstraction procedure continues to be followed as expected. Logger module receives the clientID from its client. A dedicated worker thread is the engine of the whole mechanism and drives the loggingprocess. It waits for data frame event signals of the buffer; retrieves frame data, formats the same and finallylogs the formatted frame data into a log file, through other specific objects acting as agencies. Loggingconfiguration aspect is addressed by an object denoted by Logger_ (e.g., for CAN the class name is

CFrameProcessor_CAN). The following component diagram explains this mechanism. No particular bus name ismentioned, which means the procedure manifests for any vehicle standard support.

BUSMASTER | Architecture Design | 43

The following sequence diagram shows the configuration and logging activation / deactivation process.

The below class diagram shows the implementation aspect. This largely involves identification of the commonactivities across all target vehicle bus standards and group them together in terms of classes. Here the emphasisis on reuse through inheritance and encapsulation through proper abstraction. The entity ‘Logger_’,in all its possible manifestations (e.g., Logger_CAN, Logger_J1939, Logger_FlexRay etc) exhibits the samecharacterisation of activity which is – waiting for a data event from the message buffer, retrieving frame data,formatting the same according to the present formatting conditions imposed and logging the resultant string intothe target file or file list. The services rendered can easily fall under a distinct category of their own. Uniqueoperations for a particular vehicle bus are the frame data being dealt with, the formatting intricacy and a fewrelated subtle operations.

The inheritance is governed by the following directives derived from the above analysis:•

Logger_ class is inherited from the interface virtual class

44 | BUSMASTER | Architecture Design

•••

The common or generic activities translated into another class (to be called CFrameProcessor_Common)CFrameProcessor_Common drives the whole mechanism and Logger_ is inherited from it too.The unique operations are prototyped as generic methods and hence can be invoked from

CFrameProcessor_Common. They are declared pure virtual and hence the derived class must implement thesame.

BUSMASTER | Architecture Design | 45

46 | BUSMASTER | Architecture Design

Message Window

Modus operandi of message window is similar to Bus statistics or logger modules. Here also the generalfunctional part and the vehicle standard specific routines are grouped asunder, into non-cohesive units. Fromdeployment viewpoint the general functional sub-module resides within the application whereas the dataformatting routines are realised in a DLL called PSDI_. The below component diagram shows themechanism.

The behavioural aspect of message window module is outlined with the following sequence diagram which showsthe initialisation and normal usage instance.

BUSMASTER | Architecture Design | 47

The class design approach is similar to the logger module. The class diagram is presented below:

48 | BUSMASTER | Architecture Design

Filter

Session Replay

For both the configuration and replay session running the trigger comes from the user. The replay client delegatesthe service requests to the replay module through its interface. A replay interface manager manages the interfacefunctions and routes the calls appropriately to the replay manager which employs the appropriate sub-modules tocarry out the desired tasks. Replay data processor entity accesses the input log file and loads its’ data to be treatedas the working data set of the replay session. Non-interactive replay window object provides the fundamentalreplay functionalities such as ‘step’, ‘go’, ‘skip’ and accesses IDIL_ to exploit the frame transmissionfunctionality of the later.

BUSMASTER | Architecture Design | 49

As the feature set of interactive replay window object is a superset of the other replay window, the formeraccesses the later for its execution. Both the windows are passed the data contained in replay data processorobject as the input data from the replay manager.This is also depicted in the following sequence diagram.

50 | BUSMASTER | Architecture Design

The concrete implementation takes place by a class arrangement described by the following class diagram.

Node Simulation

Design description of node simulation starts with a short prologue on a typical node ensemble and the role ofBUSMASTER in the simulation.

BUSMASTER | Architecture Design | 51

The above diagram exemplifies a cluster of CAN nodes from user’s perspective and how BUSMASTER is goingto simulate the chosen nodes.

Above is shown what it means from the developer’s perspective to simulate one or multiple nodes, from a closerview with the visibility of the bus controllers. Some controllers can simulate multiple nodes. In case it doesn’tBUSMASTER does it. Each node simulation is realised by a DLL running in the context of the application. Also,every node should be able to carry out certain bus specific operations (like frame transmission, connecting /disconnecting from the network etc) and hence a suitable API with required services must be available for theDLL. The services must best be rendered by the application.

Function editor module makes it possible to generate the DLL from a user-edited ‘C’ file. The below diagramshows the building process:

52 | BUSMASTER | Architecture Design

Please note that an object file is necessary for extracting the application’s API set for a particular bus.For Function Editor the primary bus specific entities are application API set and database information. So it ispossible to implement the function editor in a generic way and dynamically configure it by the respective busspecific client. The below diagram describes this process.

BUSMASTER | Architecture Design | 53

The execution model of node simulation is depicted below. It is the application that mobilises the activity withthe reception of the handlers (message, error event etc).

| BUSMASTER | Architecture Design

BUSMASTER | Architecture Design | 55

Frame Transmission

Signal Watch Window

The modus operandi of this component, like other modules viz. bus statistics, message window etc, centresaround the already defined concept of abstract data channelling. The only addendum is usage of the loadedmessage database which is part and parcel of the usage of signal watch window. In fact, without any associatedmessage database, usage of this module bears no significance. So, configuration is an absolute prerequisite.Signal Watch Window operations covering both the configuration and signal watching activities are explainedwith the following component diagram with necessary annotations.

56 | BUSMASTER | Architecture Design

The below sequence diagram shows the initialisation and the signal watch operation sequence details.

BUSMASTER | Architecture Design | 57

Test Automation

Services of Automatic Test Framework may be harnessed in two ways namely, through a GUI and through anAPI set. The services are categorized in two different sets – A. Test Setup Editor and B. Test Suite Editor andExecutor. The GUI modules of both of them employ the related helper modules or API sets. This is illustrated bythe following component diagram:

58 | BUSMASTER | Architecture Design

Clearly, the client application interacts with the user interface modules that employ services of helper modules /libraries to serve the client application. The client application service interface is needed to carry out operationslike frame transmission, interaction to virtual bus etc.Below is a reiteration of the software’s functions:

Test Setup Editor: This is the editor of a test setup file, with which it is possible to define and modify a number oftest cases. The test setup editor UI is the front-end and realised as graphical user interface. Data manipulation iscarried out by Test Setup Editor Library module and the artefact generated is the xml based test module file.Test Suite Editor and Executor: Its purpose is twofold – the first one is defining and manipulating a test suite andsecondly, executing the same by running the selected test setups and test cases. Output of the editing is a bytestream which the client application can store somewhere.

The Test Suite tree contains consistent types of leaves all being test setups that contains only test cases. Hence forTest Suite Editor and Executor Lib, just a set of API is sufficient. On the other hand, the Test Setup tree containsleaves of varying kinds going into varying hierarchy levels and given the functionalities like repositioning, it isbest to define the Test Setup Editor Lib interface as a container class with all the other entities being inheritedfrom a common class owing to their sharing of certain functionalities.

Because the UI truly reflects the data, test case editor lib and test setup editor & executor lib are having same usecases as the user interface modules.

Test Setup Editor Lib module

This helper module is responsible for manipulating Test Setup file acting as an interface to the file and the TestSetup data repository. The services to be rendered by this module are first listed and then translated into an APIset or a suitable class hierarchy.

BUSMASTER | Architecture Design | 59

Test Suite Editor and Executor Lib

This helper module realises defining and updating of a test suite node along with its execution. Services providesby this module are listed down with a use case diagram.

60 | BUSMASTER | Architecture Design

Test Setup Editor

This helper module basically manipulates entities of varying kinds. For example – a test case node contains fourdifferent kinds of sub entities or nodes. Also, sub entities like send or verify also contain their own message sub-entities whereas nodes like wait, replay are simple nodes. Nevertheless, all of them must exhibit functionalitieslike addition, deletion, modification of self. Also, repositioning of a sub entity is also a desired functionality.Therefore, it is the obvious decision to inherit them from a common base class named as CBaseEntityTA(TA stands for Test Automation). Also, each of the objects has a data part. The overall class structure maybe expressed by the following class design diagram where the Test Setup Editor Lib is realised by the classCTestSetupEntity

BUSMASTER | Architecture Design | 61

Automation Server Interface

The interface set has been defined in such a way that it renders the basic functionalities from BUSMASTERapplication suite. A concise view on the interface is provided below by the following class diagram.

62 | BUSMASTER | Architecture Design

BUSMASTER | Interface Design | 63

Interface Design

User Interface

•This section is applicable only if there is a human interface. Give reference to GUI standards document, if any.Mention about the GUI standards used as the basis for the design. Refer Guidelines on Database Design for moredetails.

Component Interface

Test Suite Editor and Executor Lib

Interface of this module is tabulated below:

Name &prototypeHRESULTSelectBus([in]eTYPE_BUSeCurrBus)FunctionalitySets theCurrent bustype for testsuite.ParameterdetailseCurrBus -Current busindicatoromName -Intended nameof the testsuite.omFilePath- Path of thetest setup filedwID - Theunique ID ofthe test setupif the functionis successful.dwID - ID ofthe test setup.omFilePath -Path of the testsetup filedwID - ID ofthe test setup.Return valuesRemarksS_OK,ERR_NOT_IMPLEMENTEDvoidSets name ofSetTestsuiteName([in]the test suiteCStringomName)HRESULTAddTestSetup([in]CStringomFilePath,[out]DWORD&dwID)Adds a testsetup-S_OK,ERR_PATH_INCORRECT,ERR_FILE_INCORRECT,ERR_ALREADY_ADDED,ERR_BUSTYPE_MISMATCHHRESULTRedefines anUpdateTestSetup( [in]existing testDWORDsetupdwID, [in]CStringomFilePath)HRESULTDeletes anDeleteTestSetup( [in]existing testDWORDsetupdwID)HRESULTEnables /EnableTestSetup( [in]disables a testDWORDsetupdwID, [in]BOOLbEnable)S_OK,ERR_PATH_INCORRECT,ERR_FILE_INCORRECT,ERR_ALREADY_ADDEDERR_WRONG_IDS_OK,ERR_WRONG_IDdwID - IDof the testsetup. bEnable- TRUE toenable, elseFALSES_OK,ERR_WRONG_ID | BUSMASTER | Interface Design

Name &prototypeFunctionalityParameterdetailsdwID - ID ofthe test setup.dwIDPreceding- ID of thepreceding testsetup entry. Ifit is invalid (=ID_INVALID),the shiftingentry shifts tothe frontmostposition.dwID - IDof the testsetup. unTotal- Total numberof test casesdwID - ID ofthe test setup.unIndex - Zerobased indexof the testcase. sTCInfo- Test caseinformation.dwID - ID ofthe test setup.unIndex - Zerobased indexof the testcase. bEnable- TRUE toenable, elseFALSEpfResultTC- Address ofthe callbackfunctiondefined in thecaller whichwill be calledas a result ofeach test caseexecution.This can benull.Return valuesRemarksHRESULTRepositions anRepositionTestSetup( [in]existing testDWORDsetup entrydwID, [in]after anotherdwIDPreceding)one.S_OK,ERR_WRONG_ID,ERR_WRONG_ID_REFHRESULTCall to getGetTestcaseCount( [in]total numberDWORDof test casesdwID, [out]occurringUINT&under a testunTotal)setup.HRESULTGetter for aGetTestCaseInfo( [in]test case basicDWORDinformationdwID,like its name[in] UINTand selectionunIndex, [out]status.STestCaseInfo&sTCInfo)HRESULTEnables /EnableTestCase( [in]disables a testDWORDcasedwID,[in] UINTunIndex,[in] BOOLbEnable)HRESULTExecutes theExecute( [in]enabled testPFCALLBACKRESULTTCcasespfResultTC)S_OK,ERR_WRONG_IDS_OK,typedef structERR_WRONG_ID,STestCaseInfoERR_WRONG_INDEX{ Cstringm_omName;BOOLm_bEnabled; };S_OK,ERR_WRONG_ID,ERR_WRONG_INDEXS_OK, Callbackfunctionprototypedefinedas: void(CALLBACK*PFCALLBACKRESULT)([in] DWORDdwTestsetupID,[in]CResultTC&Result)BUSMASTER | Design Alternatives | 65

Design Alternatives

No alternative design consideration because the only one has been found to be the best suitable so far.

66 | BUSMASTER | Design Feasibility

Design Feasibility

Design feasibility has been ascertained by theoretical analysis of the interface design of the two helper modules /libraries. Moreover, prior experience in somewhat similar data manipulation class design and implementation alsocontributes to the confidence.

BUSMASTER | Design Tools used | 67

Design Tools used

Enterprise Architect is used as the design tool

68 | BUSMASTER | Additional Hardware and Software required

Additional Hardware and Software required

No additional hardware and software other than what is being used in BUSMASTER development, is necessary,at least to run in simulation mode. But in order to use it with the network, one of the supported controllers has tobe procured.

BUSMASTER | Test Strategy | 69

Test Strategy

Both manual and automated testing is utilised. For the later AutoIt environment is utilised.

70 | BUSMASTER | References

References

List of all external sources of information referenced in this document.

SI. No.DescriptionDateVers.LocationDescription, date, and version shall uniquely identify the information source, and the location shall specify whereit is to be found.

References to books or journals may be given using the following format: Author [s]: Journal Name / BookName, publisher, date of publication.