And daily the V-diagram says Hello – because of different theories on the development process of an "Embedded system", companies have used many different development tools in the past seven years. Unfortunately, this uncontrolled growth of tools does not really achieve its aim. The consequences of clear requirements by companies for continuous development processes with flowing or automated tool transfers are that manufacturers who previously had strictly separated sections in such design processes now work together. This has advantages for customers, for only in this way can processes be simplified and speeded up and products become reliable and robust. The integration of emulation and debug technology in the graphic standard development environment LabVIEW from National Instruments is the first step in the required continuity. This integration brings together previously strictly separated sections of software development for the implementation and integration of software and hardware, as well as tests of all types from modules to systems.
Motivation - Embedded Systems Development and Test, a Survey
The beginning of this vision of the creation of a "Universal engineering Tool" is only a few years old. Today we are near to the stage of practicality of such a universally useful tool. It cannot be denied that National Instruments with its graphic programming environment LabView and a wide palette of interlinked hardware has revolutionized the instrumentation and automation world. The simple idea behind this is: a picture is worth 1000 words and is decisive for a high degree of acceptance by the user today, is intuitive to use, easy to learn, re-usable, has a broad area of application, adherence to standards, etc.
Fig. 1: Idealized picture of the software/hardware development processes today. From the idea to the product with the use of corresponding development tools. Here it is important that the individual development sections flow smoothly into each other. Interruptions in transfers lead to inconsistencies in the overall development process. The added values such as re-usability, shortening of development times, increase in quality are lost.
Things that were undreamt of in the development and testing of embedded systems. Projects are still executed in the handy C or C++ code (partly also still in assembler), specifications or performance specifications are available in text form; too little testing is carried out or not automated. For the past few years the buzz word in the market has been model-based or graphic development and testing of embedded systems. When the affected persons are asked, there are answers such as: "Modelling yes, but coding, as in the past, by hand," or "we have been evaluating tools for modelling for a long time, but they are only partly in use," or "we must have a grip on the code in order to implements performance," etc. In the embedded field, these are standard answers in the attempt to integrate model-based development in the daily project business. Very special and different are the requirements especially for real-time and safety-critical systems (limited resources such as memory, time behaviour, many different 8/16/32 Bit microprocessors, hybrid forms with DSP,…) than that the software development process can be made continuous from the modelling via the complete generation of code to parallel testing.
Yet?
The way there is a must as otherwise there is no possibility of coming to grips with the increasing complexity of today’s embedded software. Costs, proneness to error and thus product acceptance by the customer are lost, queries, such as in the automobile branch, pile up.
Creating flowing transfers – virtual instruments connect the graphic programming world with InCircuit- and OnChip-Emulation
It stands to reason to ask why LabView is not being used for the development and testing of embedded systems. Nevertheless in the early phases of the development process for building prototypes or also in the later test phases for erection of test stands, use is already being made of LabView and corresponding NI hardware. And yet the development and integration processes of hardware and software and the further phases of the development and test process do not flow into each other. Often the know-how gained or developed in the earlier phases is given up because the corresponding automations and connections between the tools used are missing.
Fig. 2: Incorporation of iSYSTEM VIs in a LabVIEW program. Besides the “remote control” of general project management and debugger functions of the development environment winIDEA from LabVIEW, there are available special VIs for memory and register access. VIs for executing special InCircuit-Emulator properties such as Trace and Profiler are in preparation.
As a few basic innovation steps are still required on the part of the tools manufacturer for developing or graphic programming of complete embedded system applications (such as the further development of code generators for 8/16/32 Bit processors, creation of Debug possibilities, etc.) our intention was to first bring together the two existing worlds of graphic programming or visualization via LabView and the currently used Circruit- and OnChip-Emulators [1] for software/hardware integration. The user interface for emulation, although intuitively usable, often offers only little possibility of graphic display of displayed data. If, now, am emulator is connected with the Frontpanel of LabView, then the user automatically has at his/her disposal numerous graphic depiction possibilities for analysis of the behaviour of an embedded application of the target system. On the other hand, the LabView programmer with such a connection and without special know-how of the operation of the Emulators of Debuggers can almost remote-control these in the well-known graphic program methods of LabView (via virtual instruments) [4]. This means that with a LabView program, a microcontroller application can be loaded on to a desired target hardware, applied and tested there. The results of the tests or the behaviour of the application can then again be uncoupled in tools such as LabView, Diadem,etc. [3]
iConnect_CreateInstance.vi
Creates instance of iConnect connection to winIDEA.
iConnect_IDE_Workspace.vi
Open, close, save, create winIDEA workspace
iConnect_IDE_Document.vi
Manages winIIDEA documents
iConnect_Debug_RunControl.vi
Execution control of the CPU
iConnect_Debug_GetStatus.vi
Returns debug status
iConnect_Debug_SetBreakpoint.vi
Sets, clears, enables or disables breakpoints
iConnect_Debug_Modify.vi
Modifies string expression with numeric value
iConnect_Debug_Evaluate.vi
Evaluates string expression to numeric value
iConnect_Debug_WriteMemory.vi
Performes CPU memory write
iConnect_Debug_ReadMemory.vi
Performes CPU memory read
iConnect_Debug_WriteValue.vi
Writes numerical value to the CPU memory address
iConnect_Debug_ReadValue.vi
Reads numerical value from the CPU memory address
iConnect_Debug_ReadRegister.vi
Evaluates register name to numeric value
iConnect_Debug_GetSymbol.vi
Evaluates address to symbol C symbol expression
iConnect_Debug_GetAddress.vi
Evaluates expression to address, type info and type size
iConnect_Debug_GetSourceAddress.vi
Evaulates source line (strSourceFilename and u32LineNumber) to address
iConnect_Debug_GetAddressSource.vi
Evaluates address to source line
Table 1: List of presently available VIs for remote-controlling the iSYSTEM InCircuit- and OnChip-Emulators.
Application field: Test automation at the EDAG Engineering + Design AG
These ideas are not only visions; at the EDAG Engineering + Design AG, the subject of continuity in the software development process has been a reality for several years. For this purpose, a continuous concept and system has been developed that automates software in the Loop Test via software integration test of series devices up to the test in the vehicle for the automobile industry [2].
Test cases from a test specification (available in the form such as Doors database) are extracted, automatically run through, the corresponding test results are quantitatively evaluated and written back into the same database. One speaks here of a closed validation process that offers a group of software developers and test engineers the possibility of working with an own database as well as chain of tools. Both parties can profit from each other as regards the test concepts.
Fig. 3: EDAG test automation on NI PXI HW basis and with the graphic LabView integrated emulation and debug technology development environment
These test concepts today contain a very high degree of software effort in the area of diagnostics. Various points of a control device software must be accessible, as only in this way will an optimal test execution be possible. In addition, data acquisitions such as program conditions, EPROM parameters, controller modi, etc. are required.
A classical way is the transport of this information via a CAN Bus. The software developer must develop special auxiliary functions that are inserted into the existing program code. This leads to increased loading of the Bus and requires the validation of these auxiliary functions.
The aim is to counter these "weak points" or extra efforts as much as possible. A complete saving of the CAN diagnostic is not advisable (e.g. controlling production line-end and vehicle workshop) but still, a possibility must be found in which, for instance, EPROM parameters can be accessed during a vehicle test.
This leads finally to the idea of using an OnChip-Emulator in all development phases. With this, additional diagnostic, information can be read out without influencing the existing software.
A further aspect is the possibility, within a test execution and on the basis of the acquired results, of modifying the definition of test case or to cancel the test case based on analogies with tests that have already been carried out. In this way a constant optimation as well as improvement of the test quality is achieved.
The test automation described above was carried out by the EDAG Engineering + Design AG also for a National Instruments based development environment. With the integration of the iSYSTEM emulators via corresponding VIs for "remote controlling" of these devices, additional information is read out not only over the CAN Bus but also directly over a (real-time) memory access in the control device.
Bibliography
[1] Erol Simsek: Debug-Welten. Leistungsmerkmale von InCircuit- und OnChip-Emulation am Beispiel von Freescale-Mikrocontrollern. MECHATRONIK, Entwicklermagazin für Elektronik, Mechanik und Mikrosystemtechnik, Hanser Verlag, 11-12/2004, S. 24-26.
[2] Alexander Siegel: Durchgängiger Prozess zur Umsetzung von automatisierten Komponenten- und Systemprüfungen. Handout zum EDAG-Vortrag am Automotive-Technologietag, 12. Mai 2004, Böblingen.
[3] iSYSTEM Handbuch für iCONNECT for LabVIEW: Getting Started. November 2004.
[4] iSYSTEM Handbuch für iCONNECT for LabVIEW: Reference Guide. November 2004.
