Month: April 2021

King of the H.I.L. welcomes you to the Court (Part 1)

Published on by Michael BurkeLeave a comment

I started out my career on the G.M. project SimuCar; a full vehicle simulation for Hardware in the Loop validation which models transmissions and HVAC systems. The project introduced me to the requirements and rigor of Real-Time simulation as well as the practical limitations of hardware “bucks.” From there I transitioned to Applied Dynamics International (ADI) a Hardware in the Loop vendor; in that role I developed a passion for rigorous simulation based testing. Since that time I’ve had a chance to work with all of the major vendors: Speedgoat, dSpace, Opal-RT, and NI. Each vendor has unique strengths, but they all share common requirements in getting you “up that H.I.L.”(1)

Planning your summiting

A H.I.L. system has 5 principal components:

  • The target controller: the unit under test.
  • The physical H.I.L. system: the environment that provides signals to the controller
  • The plant model: the simulated environment used to stimulate the controller.
  • The test runner: infrastructure for running the system, collecting data, and evaluating the results.
  • Wires and signal conditioning: the physical connections and mechanical/electrical conditioning used to “close the loop” between H.I.L. and controller.

Today I want to talk about how to plan out your first foundational stones of the H.I.L., the signal conditioning.

The wiring and signal conditioning

In my first year at SimuCar by my estimates my “initial” physical models would have destroyed close to 3 million dollars in GM proto-type hardware if we hadn’t first validated the wiring and signal conditioning. So here is how to commission your H.I.L. system:

  • Run the loopback harness: most H.I.L. companies provide a stand-alone loop back tests that enable initial validation of the hardware.
  • Beep your harness: the wiring harnesses connects the H.I.L. system to the controller. A wire connection test ensures that the H.I.L. and controller are correctly exchanging information.
  • Open loop connection validation: connect the controller to the H.I.L. system with a no-controls version of the controller to validate signals are correctly red on the controller.

What is a “no-controls” model?

The basic model architecture for a H.I.L. system plant model decomposes the system into three top-level components: Inputs, Plant and Outputs. Likewise, the controls model is decomposed into the OS, I/O, and control algorithms. The no-controls algorithm pairs a H.I.L. model without plant and a controls model without controls algorithms present. The test system then exercises the outputs and validates that they are correctly read into the controls system via the monitoring stack.

Once the signal connections and scaling are validated the same “no-controls” H.I.L. model can be reused in the testing environment.

Footnotes

  1. The initial commissioning of H.I.L. systems is critical for long-term success. This blog post aims at providing the tips for your base camp.

Head in the Cloud

Published on by Michael BurkeLeave a comment

The phrase “head in the clouds” describes a person who is dreaming and not focused on practical activities. But for software development where CI/CD activities run in the cloud, it is important to “get your head in the cloud.”

Develop, Distribute and Deploy

The cloud is generally used for one of three activities:

  • Development: The development workflow includes verification testing and build activities.
  • Distributed execution: In this case, the product runs in the cloud for faster execution
  • Deployment: Both the release of software and the collection of data from the field for further updates.

In today’s post we are going to focus on what makes cloud based development different from local, e.g. “desktop” based development.

Massively parallelized development

Deployment of development activities to the cloud means that the testing and code generation tasks are executed in parallel.

  • Determine task dependencies: The minority of CI tasks have dependencies. However for those that do, it is important they execute in the same thread.
  • Determine halting conditions: The greater resources of cloud-based systems often leads people to ignore “halting” conditions resulting in wasted execution cycles. The sooner an invalid CI activity is halted the sooner the root cause issue can be addressed.
  • Group by common setup: Some CI activities have expensive setup activities. These tasks should be grouped together.

Reporting and logging

When running in the cloud versus on desktop the reporting and data logging becomes critical. In most cases cloud based runs execute in virtual machines and when the task is done the VM no longer exists. Because of this, diagnostic messages and data logs are critical for debugging issues in the results.

Because it is there…(When to use your H.I.L.)

Published on by Michael BurkeLeave a comment

There is a famous quote from George Mallory; when asked why he was trying to climb Mount Everest he said “Because it is there.”(1) Unfortunately this is sometimes the approach that is used for when to use a Hardware In the Loop (H.I.L.) system; it is used “because we have it.”

Integrating a model into a H.I.L. system requires additional work which is not used on the final product. As a result, use of the system should be restricted to when it is needed. In this post I will review the primary reasons for using a H.I.L. system.

Validation of a 3rd party controller

Some “Third Parties”

The simplest reason for using a H.I.L. system is when the unit under test (UUT) or part of the overall system is a third party controller where you do not have access to the source code for simulation based tests. Common tasks in this example are fault detection and boundary condition testing.

Timing studies

Connecting a controller to the H.I.L. system enables complex timing studies of the controller, e.g. determining the mean, max, and statistical variation in timing for the algorithm.

Fault injection / Noise

While fault injection(2) and noise simulation can be performed in a simulated environment it generally requires modifications to the control algorithm to support this; as a result it is preferable to perform these tasks on a H.I.L. system.

Difficulty in modeling physical systems

In some cases, the creation of a physical model has a high cost in development time (3) whereas the actual physical component(4) can be hooked into the H.I.L. system easily. In this case having the physical component enables development that would not be possible in simulation and would be difficult or impossible in the actual environment.

Footnotes

  1. George Mallory died in his attempt to climb Everest, with Sir Edmund Hillary being the first to reach the top of the mountain.
  2. On my first job we designed an automated Break Out Box which was marketed as Auto B.O.B (this was for the automotive market). The running joke when there were any problems on the project was “It is Bob’s fault.”
  3. High cost in this case means the total engineering development time.
  4. When a physical component is hooked into the system it is called a “buck.” The first time I encountered this was with an early A.B.S. system. The brake dynamics were too fast to model and the tire/brakes system are easy to install.

Statistically, Model-Based Design is the way to go…

Published on by Michael BurkeLeave a comment

One of the most common objections to adoption of Model-Based Design is “I can write that code more efficiently.” My answer to that statement has been the same for 20+ years:

  • An exceptional programer can write more efficient code
    but
  • The average programer will not
    and
  • There is an opportunity cost when your best programers are working on “day-to-day” tasks.

On average, the generated code will be better then the handwritten code and your controls and software engineers will have more time for the tasks beyond coding.

Consistency is the key

When I wrote the last header I had an “off-by-one error”;(1) my fingers were shifted over on the keyboard and I wrote: “cpsostemceu os ,pmarcj.” This error was easy to spot, but an actual “off-by-one” can be hard to see.

This is where Model-Based Design shines; automated code generation will not make typological errors and it provides a simulation environment in which to see design errors.

Training and patterns (guidelines) for success

It is still possible to have design errors when working in the Model-Based Design environment; these arise from developers incorrectly using a block or having incorrect settings for the model. These errors can be avoided through the use of modeling guidelines (MAAB) and detected through he use of Simulation. In the meantime consider taking a course to better understand the MBD workflows.

Footnote

  1. Off by one errors explained: