Processor-In-Loop Simulation: Embedded Software Verification & Validation In Model Based Development
By Mangesh Kale, Narayani Ghatwai, Suresh Repudi (eInfochips)
Introduction
Embedded software designs such as those for avionics and automotive systems became highly complex to cultivate, make sure certify. Due to this fact, the traditional document driven environments, without coordination among involved developers, are quality and expenses from the lifecycle of those embedded software systems. Within this context, model-based design (MBD) processes when used effectively, supply a unified design environment so developers will use one particular group of models for his or her entire lifecycle for requirements validation, data analysis, model visualization, testing and validation, and consequently product deployment, with or without automatic code generation. Model-based design is often a framework for virtual prototyping of embedded software. MBD changed to conquer the contests and complexities that typically occur in the design lifecycle of embedded software for closed- loop control systems or DSP applications. Such software needs to be printed in an iterative manner with extensive involvement of multi-disciplinary teams. In the majority of from the practical scenarios, such embedded software design needs to start (along with tested) before physical prototypes and systems are obtainable. With traditional design processes, the invention of errors in design and needs are only late inside design cycle, which will bring about expensive delays. MBD framework targets to cope with such issues at the beginning of the design and style phase and it may significantly minimize the rework in later phase with the life-cycle.
A crucial component of model based development process is verification and validation of code on embedded CPU or DSP. This enables detection of flaws within the procedures that entail algorithm design to C code conversion, and enables pre-emptive measures to mitigate problems related code compilation, binary code optimizations along with CPU/DSP architecture specific limitations. Nearly all of such design issues, or else identified, can pass undetected through functional performance testing done typically within offline simulation environment for example Simulink.
Background:
As embedded software gets more complicated, those things of design, verification, validation and testing becomes more complex to truly see the and justify. The model based development process adapts utilization of graphical models in an effort to accord using the increased intricacy. Such model-based development is additionally linked with simulation, graphical types of product power to enhance verification and validation processes as shown in the Figure1.
Model based development and testing:
In MBD environment, the style team develop models to research and formulate top level, together with the meticulous low-level requirements. Such models can offer the chief architecture with the solution, however are usually independent to the embedded target platform. Such design models implement major requirements which really can be proved in exact manner in the simulation and to illustrate the deducible top -level requirements, often specified as an executable specification.
The sharing of model artefacts and efforts between the design and testing teams makes it possible for further confirmation of embedded code to hardware specific requirements, and enables an increasingly concentrated testing of the code and fixing of errors from a lesser time. The verification, validation and associated testing activities usually are implemented at most stage within model based design process. Test mechanisms (tasks) that verify, validate, and try out the model and software include:
- Model-in-Loop (MIL) to examine the algorithms during the simulation environment at early stages from the development cycle
- Software-in-Loop (SIL) to warrant the conduct of the generated software code found in the controller
- Processor-in-Loop (PIL) provides a framework to verify a controller code on a dedicated microcontroller or DSP that interacts having a simulation inside software environment
- Hardware-in-Loop (HIL) for real-time testing involving actual system components
Model design and testing:
The foremost within the integration level will be based upon the model of the program itself. Testing an embedded system design to the MIL (model-in-Loop testing) level signifies that the model along with its environment are simulated (interpreted) inside the modelling framework without the physical hardware components.
This allows testing at the initial stage with the development cycle. What’s more, it validates the wants used because the initial point of the growth process. Information gathered over the simulation becomes the benchmark for code verification.
In it, the model is adapted further in accordance with the end goals with the embedded platform. The controller model is coded in C or C++ (is often auto-generate code) and inserted into the simulation environment to examine it together with the plant simulation.
This variety of validation is very helpful for it components containing a combination of generated code and handwritten code that have to be integrated and executed for the embedded target platform. The SIL tests typically reuse the data and model structures from MIL for examining the code behavior in simulation. Generally, the embedded software and also the simulated environment model train on exactly the same machine.
Processor-in-loop testing:
This step incorporates changes towards the controller code for embedded hardware features which allows execution and tuning around the target microcontroller or DSP. The PIL setup involves loading the compiled object code on top of the target processor or DSP after which run the simulations over the plant model for verification. It’s a non-real time setup so therefore allows execution of a large wide variety of V&V test suits to evaluate embedded CPU/DSP ability to run controller algorithms. Should there be differences between SIL and PIL results, then PIL object code is fine-tuned (for instance) for fixed-point precision, memory footprint or compiler optimization flags and many others.
Hardware-in-loop testing:
After the controller code has long been verified using PIL, step 2 usually involves substituting the guarana plant model with the actual system (or even a lab prototype) or perhaps a real-time simulator running the plant model. One example is, if the DC motor speed controller has been designed then an controller code is deployed on the microcontroller or DSP board which is then interfaced to your real DC motor by connecting the inputs and outputs on the interface points such as sensors and power electronics components.
HIL testing is among the list of last integration levels which allows debugging and evaluation of functional and operational tests within a manageable way in a real-time environment. Normally a substantial volume of software based test automation and logging, and also hardware interfacing components, are necessary to implement an honest HIL setup. The PIL setup fairly easier and requirements less software and hardware resources.
PIL implementation considerations:
The main purpose of PIL should be to bridge the gap between controller model design performed in simulation software plus the actual controller code executing for the target (figure 5). The PIL approach as shown in figure 5 can get the errors that can originate while in the compiler. The PIL environment also allows debugging the algorithm functionality and evaluation from the numerical performance of embedded microcontroller or DSP. Furthermore, the PIL setup will offer important measurements of the software system such as memory usage and execution time. Such data can often adjust controller functions in the simulation environment and embedded hardware design relatively early at the outset of the planning process.
Microcontroller or DSP Performance:
The performance connected with an embedded CPU (a key component on the controller hardware) usually relies on this particular factors:
- Processor speed or clock rate
- Computational delay, Interrupt latencies
- Floating point performance or Fixed point capability
- SRAM or onboard Flash memory
- On-board peripherals which include ADC, DAC, PWM, bus interfaces
In accessory for above factors, you have to be aware that control algorithms should not be executed without certain in-evitable delays caused by ADC, DAC, de-nosing filters, de-bouncing logic and anti-aliasing filters. We have a finite time delay involving the start of a sample interval, i.e. the activation of ISR (interrupt service routine), reading of sensors along with the final update on the actuators. These all factors bring about time latencies, and even synchronization issues every time a plethora of sensor and actuation channels exist while in the system.
These latencies and computational delays be determined by the processor architecture plus the complexity within the control algorithms. By way of example, a 32 bit Arm Cortex M3 will have a superior real-time embedded performance than the Cortex Children.
The next most important parameter is cost vs performance ratio within the processor and longevity within the product guaranteed via the manufacturer.
The hardware acceleration features inside of a processor are of help to speed up tasks with less software involvement. It could enable multiprocessing, which will benefit mixed sample rate systems. The desired performance may perhaps be achieved by using a processor either with higher processing power or having a slow power efficient processor, plus a couple of hardware accelerators (e.g. Control Loop Booster feature while in the STM32 category of 32-bit Flash microcontrollers according to the ARM Cortex-M processor and TI ARM Cortex-M4F-based MCUs). Both approaches their very own benefits and drawbacks, hence, should be considered against scaling within the control system requirement.
Therefore, the choices and evaluation with the embedded processor is actually a very crucial step so helping to guarantee the intended performance of complex control algorithms, as demonstrated from the simulation, is achieved in actual implementation.
Processor-in-Loop data exchange and communication channels:
To build a communication link from the embedded processor-in-loop simulation setup typically interfaces which include SPI, UART or I2C are utilized. The simulation environment running around the host computer communicates with the object code executing on the microcontroller or DSP, typically in an evaluation board, as shown in Figure 6.
The simulation tool sends your data values on the plant model for the firmware within the evaluation board over the high-speed serial link and receives the results on the firmware using it . and other communication channel.
Such communication link allows testing from a non-real time in ways that the embedded platform (while using microcontroller/ DSP) becomes a built-in component or subsystem from the simulation environment allowing controlled debugging, evaluation, logging, and testing.
Processor-in-Loop Research study at eInfochips
In this project, eInfochips team designed and implemented a Processor-in-loop (PIL) simulation setup for speed control over a 3 phase BLDC motor within Model Based Design environment. The motor speed is controlled by duty cycle of PWM signal, controlling the H-bridge logic and subsequent commutation. This setup (Figure 7) consists of TI (TMS320F2807) evaluation board, NI8451 (National instruments) board, CCS studio and Matlab/Simulink. Initially, an offline closed-loop simulation setup consisting of a simulation version of BLDC motor, PWM switching as well as a speed controller is implemented in Simulink. The PID controller is tuned extensively across various load conditions. This really is Phase 1 i.e. Model-in-Loop setup. Then in Phase 2, the controller is implemented as C code and after that executed in TI MCU while interfaced to motor simulation in Simulink as shown in Figure 7.
Phase 1 (MIL):
This is model-in-loop simulation including things like plant (BLDC motor) as well as controller as shown in Figure 8. A PID controller continually calculates an oversight value because the difference between desired speed setpoint and measured motor speed and applies a PWM duty cycle adjustment (1 msec sample rate). The correspondingly plots for sensed speed, controller commands and PWM switching are provided in Figure 9.
Phase 2 (PIL):
In this PIL setup, motor speed values calculated in Simulink are sent as inputs towards embedded PID algorithm running in the TI MCU. The PIL block in Simulink can an interface and passes the plant model inputs towards the code running to the embedded microprocessor (TI MCU). Similarly, the outputs with the PID control algorithm are calculated by executing code over the TI MCU (TMS320F2807) and are also then fed into the Simulink plant model via SPI communication (as shown in the Figure 10). Figure 11, 12 and 13 show some typical comes from PIL setup and complement Phase 1(MIL) translates into Figure9.
References:
- CLARENCE W. de SILVA “Sensors and Actuators Control systems Instrumentation”
- Speed Domination over a D.C. motor
- Processor-in-the-loop tutorial
- How informed testing aids embedded system validation
About Authors
Dr.?Mangesh Kale?is a Senior Solution Architect and Key Accounts Manager at eInfochips.
Narayani Ghatwai?is an engineer at eInfochips.
Suresh Repudi?is the Tech Lead at eInfochips.