Category: Uncategorized

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.

Reader Request Time

Published on by Michael Burke1 Comment

It is that time of the yea;, I am throwing the blog open to your questions about Model-Based Design and Model-Based Systems Engineering.

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:

Simulation for testing and design

Published on by Michael BurkeLeave a comment

At the heart of digital simulation for Model-Based Design and Model-Based Systems Engineering lies two fundamental approaches; simulation for design and simulation for testing. While each approach can support the other they should not be confused.

Simulation based testing

Fundamentally a test has 3 criteria:

  1. There are objective measurable pass and failing criteria
  2. The test is bounded in the scope of functionality covered
  3. The test is repeatable under simulation

These three criteria are part of the “locking down” acceptance process and define when a software object is ready for integration or release.

Simulation based design

Simulation for design is an exploration process; it is informed by the objective criteria of testing but it is not bound by the objectives. Simulation for design is an iterative process of refining the outcomes of simulation until the software object is ready for formal testing.

Transitioning between

The design based simulation activities can often be transitioned to formal tests, or barring a direct transformation they can inform the formal test. To facilitate this transitioning, a testing / design framework should be developed that allows the design engineer to simulate and evaluate the model within the testing framework while keeping the infrastructural costs for doing so low. The following basic infrastructural components aid in this transition.

  • Create a common “set up / tear down” method for models and data: The method for loading models and model data should be consistent for both the testers and the developers. A set up and tear down method enforces a common execution behavior for both groups.
  • Create basic evaluation methods for examining simulation results: While test developers are able to create complex evaluation methods for simulation results, the design engineer should not be burdened with the creation of these sorts of tools. In practice roughly 75% of initial testing can be encapsulated with standard modular evaluation methods.
  • Standardize requirement descriptions: While not required to meet the strict definition of the requirement document, the design engineer should be working towards that specification. A consistent requirements description language will facilitate the design process.

Why take training?

Published on by Michael BurkeLeave a comment

The company I work for suggests ~60 hours per year of training. In general I take a split of 2/3 new content and 1/3 known. The rationale for new content is clear but why do I refresh on the “known”?

The world turns, technology evolves

The first obvious answer is “programs and technology changes.” The MathWorks releases a new version of MATLAB / Simulink every 6 months and in each iteration there are new features and capabilities. Taking training courses online or (in the pre/post covid world) in person gives me a chance to learn about these features.

Refresh your view

No matter how long you have worked in a field there is both an opportunity to learn about parts of the field you have not worked in before and to refresh and change how you see and understand the field. (Note in this famous image, do you see the young or old woman? The arrow holds the key; is it a mouth or a necklace?)

In taking a course you learn both from going over the content and from hearing a person explain it in a way you may not have thought of before.

My training mix

And so what will I be studying this year and why?

  • Object oriented programing refresher: As more of my customers are using C++ as their development language, running through a C++ class and object fundamentals will improve my integration suggestions.
  • Machine learning for predictive maintenance: The intersection of data analysis and computational methods is a logical extension of my existing skill set as well as providing a clear focus for the Machine Learning.
  • Fuzzy logic controls systems: In all honesty, it is just an area that I have been interested in for a long time and decided this would be the year to study it.

What is your training mix?

Bite-sized MBD tips

Published on by Michael BurkeLeave a comment

Let me tell you all the ways…

The use of enumerated data types is often overlooked in the MATLAB / Simulink environment. Using enumerations offers two distinct advantages:

  1. Clarity: the enumeration name tells you what it is
  2. Boundary: When you use enumerations you can’t go outside the allowed set

For Ox only

The MUX block has been part of the Simulink pallet since the beginning. However, for signal combinations either use Vectors (same data types) or Buses (mixed data types).

A “Mux” Ox

Switch to…

The switch block is a useful block for routing basic signals. However it can result in unnecessary calculations being performed and when working with complex upstream calculations, it can decrease the readability of the model.

If the switch logic depends on past values, this can also be an indication that a State Chart would be a better option.

Flying or Invisibility or Math?

Published on by Michael BurkeLeave a comment

I first head the question “which would you rather have, flight or invisibility?” a dozen + years ago. At the time it struck me as a slightly humorous question that could prompt people to think about what they would do with an ability. Before you make a choice — flight or invisibility — here are the ground rules:

Flight means the power to travel in the air up to 100,000 feet at a maximum velocity of 1,000 MPH. You don’t have any other powers. You’re not invincible and you don’t have super strength. Thus depending on your natural strength you probably can’t carry many people with you on your flights. Large pets or small children would be key candidates.

Invisibility means the power to make yourself unseen, as well as your clothes. But things you pick up are still visible. Food and drink are visible until digested.

Key Point: These powers are things in and of themselves; they don’t grant additional powers.(1) Unlike Math.

Math:(2) The superpower that is Additive(3)

Mathematics has several cardinal points: arithmetic, logical, and geometric. From those starting points,(4) set theory, calculus, and statistics can be derived.(5) Computers and computer science grow from the arithmetic and logical branches of mathematics.

Model-Based Design (and Model-Based Systems Engineering) is in turn is based on computer science and controls theory (which in turn is…).(6)

Knowing the antecedent…

Knowing the background of MBD/MBSE shows us how to improve the outcomes of these tools. E.g. knowing where to look when there are issues of performance and how far you backtrack to determine the solution. The process I go through when I am trying to improve a performance issue is I ask myself, what is the root cause of the problem? Is it arithmetic, computational, or logical? Knowing that, I then know how to improve the problem.

Footnotes

  1. The restriction that the power is “one thing in and of itself” is to prevent the superman conundrum that you can do anything: super speed and strength and flight and laser beam eyes. This got me thinking though, could you have a superpman based on just one power that could accomplish many super-feats, and if so what would it be? Would that superpower explain some of the problems with the character of Superman’s powers? I think the answer is “Yes” and the power is teleportation. Teleportation would accomplish:
    • Flight: multiple small teleportations to give the appearance of flying (think like an animation)
    • Super strength: not actually lifting things, just teleporting them up (or bending or what not). This also resolves the issue of picking up things that are structurally unstable, e.g. they stick together because they are teleported as a whole
    • Super speed: I always wondered why when Superman did a “super fast cleaning” the plates didn’t explode due to friction. The answer: he just teleports the dirt off!
    • …
  2. In this post I am talking about math, but in reality it is critical thinking that is the true base superpower. If we think of footnote 1, it is the teleportation of the mind that takes you to new places.
  3. Pun fully intended
  4. Hmm, thinking about this, with 2 starting points we can grow linearly, with three, quadratically…
  5. Given different starting points, the same underlying mathematical theories have been derived in different fashions.
  6. The “X is derived from Y” all the way down back to first principles modeling