Getting Started with Simulink

Since the start of the digital era, telling a computer what to do has been a huge problem. Humans communicate through a set of conventions—languages—with very elaborate rules, definitions, and exceptions. New languages aren't easily born in the human world. But what about computers? They operate by means of a stream of zeros and ones, using Boolean logic; that's the binary system. The computer language is nowhere as complex as the human language, but how fast are computers at solving logical problems! The difficulty is in telling the computer how to solve a given problem, and this is the art of programming.

Nowadays there are so many programming languages that knowing at least one is as common as knowing more than one human language. Those lucky ones who do are called programmers. They're able to write the instructions that a computer has to execute (and the computer understands them—well, most of the time).

Writing and debugging a complex, real-time, safety-critical application is not a trivial task, and in big automotive/aerospace industries, a misbehaving software is definitely not an option. As an example, the 327.6 million dollars NASA Mars Climate Orbiter space probe disintegrated before landing because the ground control software used the imperial metric system instead of the international one. It sounds funny, but imagine what would happen if your car maker made such a mistake in the brake control software?

The problem with using the venerable, almighty C—still the language of choice for embedded systems—is that it isn't easy to scale up the system complexity. It's interesting to note that while the system gets bigger, the deadlines get narrower. The good old tools (code editors, compilers, and debuggers) aren't effective anymore to keep the whole development time constant while raising the software requirements.

This is the next step.

Imagine an Italian guy in Moscow willing to buy a bottle of water. Chances are that he doesn't know one word of Russian, nor the Russian shop owner knows more than two words of Italian (bella and ciao).

Our Italian guy would likely point at a bottle of water with his finger and mimic the act of drinking. The Russian shop owner would smile to acknowledge the request, and then use his fingers (or pencil and paper) to communicate the price to pay.

So what? We had visual communication. The simplest of all languages are the visual ones.

When a programmer tries to explain to his manager how a code works, he usually starts drawing blocks on a piece of paper—something like the following oversimplified example:

It isn't hard to understand that the logic flows from left to right (because of the arrows), and that two inputs will be multiplied together to obtain the output. With nothing more than a simple glance, you've understood what the computer has been programmed to do.

Let's compare it with a warning-free, standards-compliant C code:

#include <stdio.h>
#include <stdlib.h>

int mul(int, int);

int main()
{
    int u1, u2, y1;
    printf("Enter two numbers\n");
    scanf("%d%d", &u1, &u2);
    y1 = mul(u1, u2);
    printf("Here's your result,the operation done is a shining 'x'!\n%d\n", y1);
    return EXIT_SUCCESS;
}

int mul(int input1, int input2)
{
    return input1*input2;
}

Now chances are one of the following:

Either way, a visual representation of the code is much easier to understand and maintain.

Now imagine a long (several hundred lines), complex (tens of source files) code, poorly commented, highly optimized for a certain processor architecture, edited by several people without a strict style policy—the classic spaghetti code that many programmers are faced with in their job. They'll spend a huge amount of time understanding what the code does, no matter how skilled they are. Explaining that code to a colleague who doesn't know programming is out of the question.

That's where visual programming comes the rescue. A graphical programming tool can save countless hours of work in a job where explaining the code is as important as a code without bugs, or where a bug can have disastrous (safety-critical) effects.

Simulink is such a tool.

In every software project where safety is an issue, the software development starts only when a stable specification has been released.

Specifications are usually written as text documents where each sentence describes an atomic requirement and must be highly detailed.

The problem with specifications as text documents is that there isn't any way of verifying the correctness of the specified logic until the development phase or even the testing phase.

Every time that the specification is found to be incorrect or incomplete, the specification team must be notified and must make a new release. So the development team has to develop the new release, likewise the testing team will have to test the new software.

A specification error is one of the worst things that can happen in a big manufacturing company, often leading to production delays, while underspecified software can lead to unwanted behavior.

Simulink can be used to achieve the goal of writing correct and complete specifications, without losing anything in readability. Let's consider the following atomic requirement:

The corresponding Simulink block would be as follows:

What's the real deal? It is that you can test the requirement before it's released. With Simulink, it's easy to generate input signals and register the output as shown in the following diagram:

When viewing the display on Scope, the result will look like the following diagram:

But wait! Let's examine the textual requirement; it says that the flag must be set. It's unclear (not specified) whether the InputSignalFlag variable should be reset when InputSignal becomes 0 or less than 0.

But the difference is very clear in a specification done with Simulink. The following is the block diagram that describes the requirement with the InputSignalFlag variable remaining set until the end of the execution cycle:

We can see that the simulation result is very different from the previous one, as seen in the following diagram:

With textual requirements, there's always a gray area due to the fact that human languages, despite their richness (or because of it), have problems in describing a Boolean logic. And it's extremely difficult, if not impossible, to test the requirement before the release.

With Simulink models as requirements, there is no room for doubt. The requirement is complete and easily understandable by nonprogrammers, and a preliminary test can be made with little to zero effort by the very same team that wrote it.

The development team has the responsibility of maintaining and updating the software for a certain project or series of projects. The usual work flow for the embedded C developer of an automotive industry is shown in the following diagram:

The first problem developers are faced with is the code itself. A well-commented code with strict coding-style guidelines will be easily understandable and maintainable, but sadly, that's not the common situation. Code maintainability is a major issue almost everywhere, strictly dependent on code readability.

The second problem is the formal code-correctness checking. This means doing a static code analysis to check compliance with one or more sets of formal rules (for example, the MISRA-C rule set).

The third and the most important problem is code debugging. This is done by running the code to do an early testing (for example, with valgrind) and applying well-known input patterns to detect and correct the blocking bugs.

Simulink helps the pressed developer solve these problems in the following ways:.

By using Simulink, the development team can apply the required updates in a shorter time and use the remaining time to perform a quick preliminary testing of the code.

Static code analysis becomes almost irrelevant since coding rules and conventions are enforced by the code generation software.

Finally, with the autogenerated code being free of syntax errors, the compilation phase is usually straightforward. This greatly helps the programmer who is not familiar with the C syntax.

The released code needs an extensive testing phase before being put into production. The testing team's objective is to confirm that the software is compliant with the specifications.

This usually involves breaking the specifications into atomic requirements and having one or more test cases for each requirement (the so-called functional testing), or defining what should never happen and automatically apply every possible combination of inputs to the software component (a subset of destructive testing).

By using Simulink models, the testing team can easily perform automatic model-in-the-loop (MIL) testing on their computers; the logical correctness is demonstrated by applying inputs to the Simulink models and comparing the outputs to the expected behavior. MIL testing easily spots failures in a very short time and generates a detailed test report, even pinpointing the model block where the problem resides. MATLAB already has everything needed to perform an MIL test, while automated tests can be coded using the MATLAB scripting language.

Once the MIL testing is successful, the software-in-the-loop (SIL) testing is performed by running the autogenerated code on standard computers. It is usually aimed at finding discrepancies between the model and the code behaviors, and it requires another software monitoring the process's I/O or the inclusion of debug headers into the tested code, or a mixture of both.

The next testing step is the processor-in-the-loop(PIL) testing, where the software is programmed into the target processor and debugged via an external high-speed bus connected to a standard computer, such as a JTAG connection. Of course this requires having the target processor available on a board with a testing connection.

The last step is to perform hardware-in-the-loop (HIL) testing, which is running the software on the target hardware connected to a real-time system. It requires a custom test bench to be purchased or made internally, and some test steps have to be executed manually.

The biggest advantage of MIL testing is to reduce the number of times SIL, PIL, and HIL tests are performed. This is because most of the problems are caught during the fast, nonexpensive MIL tests, thereby reducing the overall time spent to generate, build, and validate the produced code.