Month: March 2018

Short answer: the real world is noisy.  If you write tests that assume clean input data you are not exercising the system in a real environment.  So let us talk about noise.

Types of noise and sources of noise

For this article, I will define noise as signal data entering the system from the outside of the system.  Sources of noise include

1. Resolution limits: all measuring devices have a limit to their resolution.  A ruler with 1/8th-inch markings cannot accurately measure 1/16th-inch resolution.
2. External interference: Frequently there are secondary effects that change the measurement.  For example, when measuring a voltage it is common to have noise in the signal from other wires running nearby.  (Which is why for some sensitive measurements shielded cables are used)
3. Dynamic property: In some instances, the value of the property being measured is changing rapidly; any given measurement may be an outlier.
4. Human error: For devices that human operators, well we make mistakes in how we enter information…

Types of noise, generally, map on to the sources of noise.

1. Quantization (resolution): Characterized by “jumps” in the value.  In dynamic systems must be tolerant of the jumps.  For static (e.g. post-run analysis) the jumps can be “smoothed” using functions.
2. White (external): Characterized by random values around the “actual” signal.  Generally can be filtered using standard transfer functions.
3. Outlier (dynamic): Characterized by occasional values outside the trending values.  If the “standard” range is known then these outlier values can be ignored.
4. Systematic (human): Characterized by systems being executed in a non-standard order.  Systems need to be made recoverable from non-standard execution order.

 

Testing the wild-noise

The basic strategy for testing with noise is to “inject noise” into the system under test.  How we inject can again be mapped back to our 4 types of noise

1. Floor functions (quantization): Use a floor function to resolve signals to the nearest value of the inputs resolution.
2. White noise generator (white): White noise generators are common functions.  One important note, if the same “seed” is used for the white noise for all runs then this test has an inherent flaw.
3. White noise generator (outlier): There is a special case of the white noise generator where signals are more episodic and, generally, of a larger value.   In these cases, a statistical model of the outlier signals is helpful in creating this white noise generator.
4. Decision tree analysis (human): Creating test cases for human error can be the most difficult.  For state logic, it is possible to analyze the system to determine all possible paths.

In the end, including noise in your tests will result in more robust systems.

Unlike many, this post is Simulink centric and deals with the question of global signal data within Simulink models. So first what is “signal data?”  Broadly speaking within a Simulink model data elements are broken into parameters (fixed) and signals (things that change).  Signals are either calculated or come in from the root level.

Within the model, the signal data is “scoped” to the line it is attached to, or in the case of a Stateflow chart or MATLAB function block, the scope of the chart/function.

The exception

Within Simulink, the exception to the rule is the Data Store.  With Data Store (read and write blocks) data can be shared in different parts of a model without the use of connecting signal lines.  Further, the data stores can be shared with Stateflow Charts and MATLAB functions.

In addition to acting as global data, Data Stores have the unique ability to be written to in multiple locations within a Simulink diagram.  Because of this ability, they must be fully defined with the data type, dimensions, and complexity when they are first created.

Global data bad……

Global data is easy to work with, allows you to quickly share information between functions and to reduce interfaces.  At the same time, it makes debugging code more difficult (where was X set?) and reduces reusability of code by expanding the dependencies of a function.  But… there are times when global data is the correct solution.

When to use global data

So with these downsides when should global data be used? As a general rule of thumb, I advocate for 3 uses

1. Error/Fault detection:  By their nature error flags can be set by multiple causes.  Because of this, the ability to write to an error flag in multiple locations is a valid rationale.  Additionally, since the error flags may be needed in multiple places in the model (more so than normal data) the ability to pass this without routing is important.
2. Mode data: A system should respond to mode changes all within the same execution step.  Like error flags, Mode Data is shared across the full scope of a model.
3. Reset flags: Reset flags are used to reset state behavior of integrators and transfer functions.

Generated code

As a final note, the global property of data in Simulink models should not be confused with the scope of the data in the generated code.  The scope of the data in the generated code (for both parameters and signals) can either be determined automatically by Embedded Coder or controlled through Data Objects.  This will be covered in a future post.

At some point in the software development cycle, the question of single or multi-threading environment will come up.  With multi-core processors more common now in embedded devices this a more frequent issue.  Let’s take a look at some of the trade off’s between single and multi-threaded environments.  For additional information, I recommend the following links

• University of Chicago CS 
• Wikipedia threading overview
• IEEE Performance tradeoffs

Single threaded

It just works, the program runs from start to finish in a set order and you know what happens relative to everything else.  However, it may be slower than it needs to be if some of the operations can take place in parallel.  If you do not have timing constraints this is a fine option to take.

Multi-threading

If single threading can be described as “just working” then multi-threading needs to be characterized in a different fashion.  We will start with some basic understanding of threads.  A thread is the smallest unit of execution that an OS can instantiate; they are either event-based or periodic (temporal).  Threaded operating systems can be either non-interpretable or interpretable.

Packaging your threads

Each thread should exhibit a high degree of independence from other threads; meaning the operations of “Thread A” should have a minimum dependence on the data from “Thread B.”  The key word here of course is “should.”  In the end the threads will need to exchange data and that is one of the complications of multi-threaded environments.

Data locking and synchronization

In a multi-threaded environment, a lock (or mutex) is a method for ensuring that a memory resource is not in use by multiple threads at the same time.  E.g. if you have a shared memory space you do not want to threads writing to it at the same time (or one reading while the other is writing).

Locks provide a way of synchronizing data between threads, however, they slow down the process since the thread cannot continue until the data is unlocked.  In some instances, when the operation of one thread is dependent on the outputs from another, if the locking and data synchronization is not handled correctly a race condition can occur.

Debugging multithreaded environments

Bugs in multithreaded processors generally occur when the expected order of execution does not match the intended order of execution.  This can be either due to

• A thread failing to start
• A data synchronization failing
• A thread taking longer than expected and preventing another thread from running

Use of a debugger to “walk through” the code is often required to get to the root cause of the issue.  However, if the bug is due to an overrun issue then using the debugger may not catch the error because in the debugging mode you are not subject to the timing limitations. In this case, either a trace log or even an oscilloscope can be employed.

For more information on debugging multithreaded environments, I suggest these links

• MSVC Debugging multithreaded issues
• Dr Dobbs: Debugging multithreading
• Stack overflow forum discussion
• Using Polyspace for detecting race conditions

 

Everyone knows that best practice tells us to put comments into our code/models; some of us do.  The question for today’s blog is “what makes a good comment?”

The good, the bad and the just simply useless

NOTE: all examples of “bad comments” are taken from real-world experience.

1. Do not repeat the information in the model:  
   For the given line of code:
   output = input * 2;
   1. Bad comment: /* The output is equal to 2 times the input */
   2. Good comment: /* Investment pays two times the deposit */
   3. Useless: /* Multiplication operation */
2. Explain why something is done in a given way:
   For the given line of code:
   bound = min(upper,max(lower,length));
   1. Bad comment: /* Run min/max functions on length */
   2. Good comment: /* Limit ouput between upper and lower bounds */
   3. Useless: /* Bound value is bound */
3. Are clearly written:  Comments should be written in the native langue following standard grammatical rules.  Avoid slang and abbreviations.
4. Are “as long as they need to be”:  Comments do not take the place of requirements.  They are in place to explain part of the model/code.  As such they should be written so they explain the concept and no more.

Why we comment?  What comments can’t do…

Comments aid people in understanding what the model or code is intended to do.  Comments need to be maintained as the source is updated; there is nothing worse then a 3 year old comment that has no relationship to the current object.  Finally, they cannot take the place of well-written code.    (In all honesty, I have no idea what the screenshot that follows does….)