CAN总线分析工具BUSMASTER

# | BUSMASTER | TOCBUS MASTER敷Desig n Docume ntCopyright 2011 Robert Bosch En gi neeri ngand Busin ess Soluti ons LimitedContentsInterface Details6Design Scope7.Design Methodology13Design Notations14Design Considerations15Design overview2.5Architecture Design26DIL_Interface2.6.IDIL_CAN27DIL_ES58128DIL_BOA2.9DIL_Stub_CAN30ConfigDialogDIL31Bus Statistics32Simulation Engine3.4.Project Configuration3.8Logger42Message Window4.6.Filter48Session Replay48Node Simulation5.0.Frame Transmission5.5.Signal Watch Window55Test Automation5.7.Test Setup Editor Lib module58Test Suite Editor and Executor Lib5. 9Test Setup Editor6.0.Automation Server Interface6.1Interface Design63User Interface6.3.Component Interface6.3.Test Suite Editor and Executor Lib6. 3Design Alternatives6. 5Design Feasibility66Design Tools used6.7Additional Hardware and Software required 68Test Strategy6.9References7.0.BUSMASTER | Lice nse In formation | 3Lice nse In formatio nThis is a free docume nt: you can redistribute it an d/or modify it un der the terms of the GNU Lesser Gen eral Public Lice nse as published by the Free Software Foun dati on, either version 3 of the Lice nse, or (at your opti on) any later version.This docume nt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warra nty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser Gen eral Public Lice nse for more details.You should have received a copy of the GNU Lesser Gen eral Public Lice nse along with this artifact. If not, see .# | BUSMASTER | Ack no wledgeme ntAck no wledgeme ntThe BUSMASTER applicati on suite evoluted from its in cipie nt stage of mon olithic si ngle bus - sin gle con troller architecture towards the prese nt stage of modular & reusable comp onent based architecture, easily and seamlessly exte ndable to support multiple vehicle buses, exhibit ing a rich set of carefully crafted feature list. Reach ing of such a milest one was possible only by the valuable con tributi ons from many dedicated and skilful professi on als who were in volved at differe nt cycles of the developme nt process defi ning the trajectories of the product evoluti on, tran slat ing many inno vative ideas into reality. The con tributors so far are Mrs. Jalaja K.V, Mr. Amitesh Bharti, Mr. Amarnath Shastry, Mr. Rat nadip Choudhury, Mr. Pemmaiah B.D, Mr. Raja N, Mr. Rajesh Kumar R, Mr. An ish Kumar, Mr. Pradeep Kadoor, Mr. Arun kumar Karri and Mr. Ven kata naraya na Makam.This desig n docume nt is the summati on of all the releva nt desig n docume nts, no tes and an an alysis report, produced and refined throughout the developme nt process, and hence is an in tegrated version prepared to roll out the OSS versio n of BUSMASTER.BUSMASTER | List of Abbreviations | 5List of Abbreviati onsAbbreviatio ns, non-sta ndard terms and acronyms that are used in this docume nt are to be listed here.APIApplicati on Programmi ng In terfaceBOABasic Open ArchitectureCANCon troller Area NetworkDILDriver In terface LibraryFlexRayA vehicle com muni cati on system developed by the FlexRay con sortiumGUIGraphic User In terfaceHLDHigh Level Desig nJ1939A CAN based higher layer vehicle bus sta ndardLINLocal In terc onnect NetworkOODObject Orien ted Desig nOSSOpen Source SoftwareRBEIRobert Bosch Engin eeri ng and Busin ess Solutions LimitedSEISoftware Engin eeri ng In stituteUIUser In terface# | BUSMASTER | In terface DetailsIn terface DetailsThis docume nt describes at len gth the various desig n aspects of BUSMASTER tool family which aims at simulta neous support of any vehicle bus sta ndard.For obvious reason the design approach primarily harps on the principle of large-scale reuse and consequently is broadly in spired by product line model to leverage on this said aspect. The approach con forms to the SEI defi niti on of product li ne engin eeri ng which is“ A set of systems shari ng a com mon set of features that satisspecific n eeds of a particular market segme nt or missio n and thus are developed from a com mon set of core assets in a prescribed way ” . So outlining of the engineering activity may be presented by the following:BUSMASTER | Desig n Scope | 7BUSMASTER | Desig n Scope | #Desig n ScopeThe modules mostly have a one-to-one mapping with the feature set the application suite. The feature list against the implementing modules is tabulated below:SI. No.Feature NameProjectconfiguration saving and retrievalModule NameProjectC on figuratio n.dllIn terface for a DILDIL_I nterface.dllof a busCAN DIL ES581CAN_ETAS_ES581.dll4 CAN DIL PEAK USB5 CAN DIL BOACAN_PEAK_USB.dllCAN_BOA.dllRemarkUsed to store project configuration data in a bi nary file which also can accommodate multiple project in formati on. If n ecessary, ODBC support can also be brought in; this is supported by its desig n.DIL stands for Driver In terface Layer and is the in terface to the bus. This abstracts out the driver details from the applicati on thereby bringing in loose coupli ng. When the query for a particular bus in terface from the clie nt comp onent to DIL_I nterface.dll is successful, this library ren ders the appropriate in terface.CAN DIL in terface to ES581.x con troller from ETAS GmbHCAN DIL in terface to PCAN con troller from Peak GmbHIn terface to BOA from ETAS which is an abstract ion to its CAN hardware in terfaces. This completely decouples the clie nt applicati on from the un derly ing hardware.# | BUSMASTER | Desig n ScopeFeature NameModule NameRemarkSI. No.6CAN con troller con figurati onCo nfigDialogsDIL.dllCAN bus simulationCAN_STUB.dll & BusEmulati on. exeFilteri ngFilter.dllImpleme nts the con troller con figurati on GUI. This makes it possible for BUSMASTER applicati on to completely get decoupled from the un derly ing hardware support. Additi on of a new hardware / con troller for a bus means a updat ing in DIL_.dll, Con figDialogs.dll and in troduct ion of _.dll. Commercial feature related files & rout ines will be take n off.The first one is CAN DIL in terface to simulatio n engine. Second one is also known as simulati on engine; this realizes a virtual bus in the workstati on making it possible for any in sta nee of BUSMASTER to act as a node and com muni cate via this com mun icatio n cha nn el. By desig n this should be able to simulate any bus hitherto known and unknown. Also, the same in sta nee of server can cater to any nu mber of buses with any nu mber of no des simulta neously.Implements filtering con figurati on dialogues. Both a composite aggregate and gen eric. Commercial feature related files &BUSMASTER | Desig n Scope | 9SI. No.Feature NameModule NameRemarkNode program ming and simulati on for CANNodeSimEx.dll10Loggi ng of frame dataFrameProcessor.dll11Play back a sessi onReplay.dllrout ines will be take n off.Realizes greater part of the node program ming features. Accommodates both function editor and node executor modules. Function editor is gen eric and is con figurable by its clie nt on the fly to cater to various bus in terface characteristics. Node executor - on the other hand contains in dividual bus specific slim sub-modules with majority of com mon modules / classes.Is utilized to log messages. When queried, this provides in terface to various sub modules specific to in dividual buses. Since loggi ng procedure is same for any bus, save the protocol specific frame in formati on, the classes all desce nd from a com mon class and employs com mon worker thread function. This results in savi ng a lot of impleme ntati on and testi ng effort. For example - addi ng J1939 support took3.5 days of effortin stead of the usual2.5 weeks of effort, thereby savi ng 72%.Implements the replay module, coveri ng both configuration and operati on aspects.BUSMASTER | Desig n Scope |#SI. No.Feature NameModule NameRemarkSI. No.Feature NameModule NameRemarkTested so far only for CAN.12Sig nal watch - CANSig nalWatch.dllImpleme nts sig nal watch win dows.Dyn amically con figurable for any bus.13CAN FrameTxWi ndow.dllImpleme ntstran smissi on - bothmessagein mono shot andtran smissi oncyclic modescon figurati on UIs and helper modules. Implemented so far for CAN.14Signal graphSigGrphWnd.dll & CGCtrl.ocx1. Responsible for man agi ngthe sig nal value display in the sig nal graph activeX con trol. Con figurable for any bus and so the bus-specific routi nes are resp on sibilities of the clie nt module.2. This is the signalgraph con trol where selected sig nal values are displayed as continu ous line diagrams.15CAN messagePSDI_CAN.dllA helper modulewi ndowfor CAN message window containing all the bus specific associated routi nes.16Test Automati onTestSetupEditorGUI.dll,TestSetupEditorLib.lib,TestSuiteExecutorGUI.dll1. This is the editor of a test setup file.&TestSuiteExecutorGUI.lib2. This is the helper libraryexclusively for test setup editor3. This definesa test suite, executes the same and saves the result in the desired format.17Database editorBUSMASTER.exeBUSMASTERapplicati on. Full25BUSMASTER | Desig n Scope |11SI. No.Feature NameModule NameRemarkdecoupli ng is not yet fully achieved; this contains some gen eric classes, modules as well. Commercial feature related files & rout ines will be take n off.18Bus statisticsBUSMASTER.exe19Automati on server in terfaceBUSMASTER.exe20Log file exportBUSMASTER.exe21Trace win dowBUSMASTER.exe22Mai n GUI and con troller & configuration for other modulesBUSMASTER.exe23Helper libraries (not feature)DataType .libSame as aboveSame as aboveSame as aboveSame as aboveSame as above24Helper libraries (not feature)Utils.libHelper libraries (not feature)Com mon Class.libImpleme nts the data types / structures that are widely utilised by any module / comp onent of BUSMASTER tool family. This was created with the idea to solve the greater part of the problem at hand by properly defi ning the data type. Commercial feature related files & rout ines will be take n off.Contains some utility services, both GUI and non- GUI, commo nly soughted after by any module / comp onent of BUSMASTER tool family. Commercial feature related files & rout ines will be take n off.Impleme nts some utility classes com monly used. Commercial feature related files & rout ines will be take n off.25BUSMASTER | Desig n Scope |#SI. No.Feature NameModule NameRemarkSI. No.Feature NameModule NameRemark26Wave patter n gen eratorSign alGe nerati on. dll, BUSMASTER.exeThis gen erates sig nals with values match ing certa in regular wave patter ns like sinu soidal, triangular, spike etc. For CAN the first two has bee n impleme nted.This desig n docume nt addresses all the required differe nt desig n aspects n amely:1. Component diagram2. State machine diagram3. Sequenee diagram4. Class diagram5. Deployment diagramSo for every module the applicable desig n will be discussed on.25BUSMASTER | Desig n Methodology | 13Desig n MethodologyHybrid desig n methodology con sisti ng of structured and object orie nted has bee n used.# | BUSMASTER | Desig n Notatio nsDesig n Notati onsFor desig n, UML 2.0 no tati on is usedFor class nomen clature, the RBEI/ECM codi ng guideli ne has bee n followed.BUSMASTER | Desig n Con sideratio ns |15Desig n Con siderati onsHere some the desig n requireme nts which are to be followed while carry ing out developme nt activities are described con cisely. The BUSMASTER applicati on desig n & architecture specificatio n, followi ng con ti nu ous associated improveme nt activities, evoluted from a vast mon olithic architecture into a properly harm oni sed en semble of loosely coupled reusable and efficie nt modules & comp onen ts. As a n atural and obvious con seque nee, certa in patter ns and structural approaches for developme nt, albeit implicit, resulted. This docume nt aims at capturi ng 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 automati on server is also possible.Towards this, a problem arises which is related to the complexity in harmonization of GUI with the applicatio n data (backe nd data).The user modifies the application data through the GUI which is a coarse visual reflection of the data. The handler modifies the data as per the user s choice and domain rules and then updates the GUI based on thehan dler or function data.It is often missed that GUI is only one of the ways to initiate application data modification activity.Explicit ness of the other one rema ins uncon sidered most ofte n. Therefore, the desig n and the very structuri ng of the sub modules & function list naturally don t support this aspect. The result is obviousa n eed arises (e.g., exploitati on of the feature from some other module while keep ing the GUI on, automated testi ng etc), bugs with syn chro ni zati on of GUI with the applicati on data, un expected crashes, duplicati on of codes etc creep in. This results in patch work, which further pervades into chaotic codi ng and many other un desirable con seque nces.A sample code is presented below. The use case deals with 5 controls and takes the services of 5 utility API calls from the applicati on data man ager library.So long as we use the GUI to run this particular use case, things will proceed as expected, in the right manner. However, whe n it is done through some other mea ns in stead, (e.g., from a tester module running the applicati on in the server mode, running the use case from ano ther sub module etc). Someth ing un expected happens most often. In case of the former, a crash in case the GUI code doesn t always validate thof the window or control handles or object pointers. In case of the later, either duplicate code and hence possibility of the GUI not appropriately reflecting the application data state. Add with it the numerous GUI con diti ons.BUSMASTER | Desig n Con sideratio ns |17Very defe nsive codi ng 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 be the most n atural and therefore, best approach./ Data_Ma nager.cppRET_TYPE Fun ctio n1_Exported(ARG_TYPE);RET_TYPE Fun ctio n2_Exported(ARG_TYPE);RET_TYPE Fun ctio n3_Exported(ARG_TYPE);RET_TYPE Fun ctio n4_Exported(ARG_TYPE);RET_TYPE Fun ctio n5_Exported(ARG_TYPE);/ GUIClass.cpp#in clude Data_Ma nager_exter n.h/ Set of functions that operate on Con trol 1 upto 3void GUICIass:Modify_C on trol1(ARG_TYPE)/ Modify con trol1 accordi ng to ARG_TYPE _void GUIClass:Modify_C on trol2(ARG_TYPE)/ Modify con trol1 accordi ng to ARG_TYPE _void GUIClass:Modify_C on trol3(ARG_TYPE)/ Modify con trol1 accordi ng to ARG_TYPE _void GUIClass:Ha ndler(ARG_TYPE) / The han dler impleme nts the logic torealize/ the desired fun ctio nality.if (Fu nctio n1_Exported(.) = SUCCESS)Modify_Co ntrol3(.);if (Fu nctio n5_Exported(.) = SUCCESS) -if ( Function3_Exported(.) & Function2_Exported(.) 一 一/ Code to update con trol 4Modify_Co ntrol2(.); _if (Fu nctio n4_Exported(.) = FAILURE) _Modify_Co ntrol1(.); _else/ Code to update con trol 5The soluti on crafted is layeri ng of resp on sibilities by in troduci ng a two-way com muni cati on with the data source. Any cha nge in the back-e nd data can be in dicated to the exist ing clie nts impleme nted either in eve nt notification or call-back function. So the back-end data or the application data manager should have a well- defi ned in terface. A typical use case can be realized by the executi on of a few routi nes in some order, with adequate parameters.O 入 UserThe soluti on con cept is in spired on the observer desig n pattern and the model-view-c on troller software architecture.2. Abstract data channel: Usage of BUSMASTER falls under two distinet categories namely, bus monitoring& an alysis, and node simulati on. Un dercurre nt of the first one is“ retrieve data and represe nt the sdesired fashion ” . All the major functionalities like frame display, logging, data interpretation, signal watch and graph, replay etc have frame data processing as the kernel of their activities. That s whimporta nee to make the data retrieval procedure efficie nt and simple. The below diagram depicts such a schema BUSMASTER | Design Considerations |19IServerThis 祐 a uoEEon scenario vxhich dEpicbthe cllenVsefYt mod电I adapition in the center of BUS MASTER. The ccirnerstone pointe are the follMving：The cliient module expect thE frame djta through some mejinis.2. Ibuffeir object is the a I hation of the above. The client mkrfa of the ssme tothe server. The interface is carefully dlesigned to佬qui胆mnts of any module &i CANvas.3. The server pumpsfrarm-e data into thE messrage data buffer qbjiect thn?ugh the interface proviided. 忖 otrfi cation takes place through eve nt-d riven approach. Whenever the b differ object 宙 populated 4/vith frame data, jn event is signijjled, The reading thread us this event to retrieve ind proa me nt exposes j set -of APII functions which supporte th* behviiomral fdturs stated dbova. Other common feature list included in the API function sat is ihitlalisaiion, uminiti訓generic getter and setter of server coMigurati on data.This calls for an optimised desig n for the message buffer classes which also qualifies the n ecessary performance criteria. Since frame data processing lies as the core of the activities, this issue is of paramount importa nce and eve n an iota of improveme nt in this directi on can sig ni fica ntly con tribute is performa nce elevati on. The next point details on this.3. Optimised data design: Reiterating the RS, this discussion continues with the disclaimer that no loss of frame data can t be guaranteed. Only the possibility of data loss can be brought down with efficient design of the data structure. In a non-real time system like Windows this can be achieved by using buffer(s) as temporary placeholder(s) of data as show n in the figure above. The con troller in additi on contains a buffer that provides the first level of buffering whereas the application buffer is the last one. Hence we have an ensemble of two buffers one from the con troller and the other from the applicati on.Hence the deciding factors can be the following:1. Size of the controller buffer2. Controller buffer m