Using code from Simulink model in HIL

Steps of converting a Simulink model to code usable in Hardware-in-the-loop (HIL) simulation:

1. Checkout/pull Simulink model from repository to your local.
2. Run Simulink model and confirm it finishes as expected. If not, inform the model maintainer and ask them to commit/push the model with correct settings to repo. 
3. Confirm that C/C++ code can be generated from model. Sometimes an s-function build file (mexw64) exists but its source code is missing, which allows the model to run but prevents code generation.
4. Copy code to Visual Studio and verify that you can build and run it. There are cases where Simulink is more forgiving of errors like uninitialized variables, or missing #include <cmath> but Visual Studio cannot build the code.
5. Copy code to real time Linux PC and verify code can be build there too.
6. Commit code to its own repo.
7. Run HIL with new code and verify HIL works as expected.

Why is file hash comparison faster than byte-wise comparison

Question: Since calculating the hash of a file requires reading every byte, why is comparing hashes of two files faster than byte wise comparison of file contents?

Answer: In hash comparison, each file's hash is computed once (by reading all its bytes), and then the two hashes, which are small fixed-size values (e.g., 256-bit or 512-bit), are compared. Comparing two hashes takes constant time, regardless of file size. In a byte-wise comparison, if there are N bytes, in the worst case where files are the same, N comparisons have to be made. 

• Hash comparison = reading file + 1 comparison.
• Byte-wise comparison = reading file + N comparisons.

LONG_MAX is different for Windows 64 and Linux 64

When you generate code with Simulink (MATLAB R2023b) using ert.tlc, the default OS is Windows 64, see Configuration Parameters - Hardware Implementation - Device type. When you generate C code, the <model name>_private.h file will contain checks for ULONG_MAX and LONG_MAX.

On 64-bit Windows, the long type is typically 32 bits, which causes the LONG_MAX to be 0x7FFFFFFF. On 64-bit Linux systems, the long type is typically 64 bits, i.e. LONG_MAX is 0x7FFFFFFFFFFFFFFF. When you use code generated with the Windows 64 setting and use that on a Linux 64 OS, the check in <model name>_private.h will fail. The solution is to use the Linux 64 setting in Simulink which removes the LONG_MAX check from header file.

This checks seem to have been added after MATLAB R2022b because code generated with R2022b does not have them.

Passing JSON to ProcessBuilder

I am using one JVM to prepare inputs for a simulation in another JVM. The simulation uses a C++ DLL, and when that DLL crashes, it takes the JVM with it. Running it in a separate JVM protects the first JVM from crashing as well. I prepare the simulation inputs as a JSON string in the first JVM and pass it to the second using ProcessBuilder. However, when passing a standard JSON, ProcessBuilder strips away the double quotes, e.g., "count": 5 becomes count: 5, which results in an invalid JSON that cannot be parsed in the main(String[] args) method. The workaround is to use jsonStr.replace("\"", "\\\"") before passing jsonStr to ProcessBuilder.

When do you need HIL tests?

The steps to create an autonomous aircraft, from design to product, are as follows:

1. Concept of Operation
2. Requirements
3. Design
4. Ground tests
1. Test components
2. Test system
5. Flight tests
6. Deployment
7. Maintenance/Updates

As you progress through these steps, the cost of fixing problems increases exponentially.

Consider a typical closed-loop diagram:

The "plant" consists of the airframe, actuators, and engine. The environment includes the atmosphere, aerodynamics, gravity, and electromagnetic interference.

During design phase, you start without any hardware and simulate everything with software-in-the-loop (SIL) simulations. The advantage of SIL is that it allows you to run millions of automated tests in a short time and with low cost to verify that you don't have any logic errors in your software. 

As hardware becomes available, you proceed to ground tests, transitioning more and more of your software from standard PCs to custom hardware. This slower and more costly step is called hardware-in-the-loop (HIL/HWIL) tests. HIL tests are necessary because:

1. Your system might work in SIL but since certain bugs only manifest themselves on a particular OS - compiler - hardware configuration, you cannot be sure with just SIL tests that your software is bug-free. Note: Instead of bug-free, the term 'tolerable' might be more appropriate because, for complex software, it is statistically improbable to achieve an entirely bug-free state.
2. Resource constraints (memory, processing power, network speed, etc.) of real hardware might differ from those in SIL which might cause a working system in SIL to fail in HIL due to missed timings etc.
3. Electromagnetic conditions (interference, noise, etc.) might differ from those in SIL. Components that work individually in isolation might cause problems when integrated together.
4. Although you can't test as extensively as with SIL, you can still conduct far more tests than with flight tests.

Music: Daydream In Blue

Visual Studio call hierarchy

With Visual Studio 2022, the call hierarchy feature has two problems:

1. Despite me being always interested in the incoming calls to a function, never outgoing callsI always have to click the "Calls To" icon for each level and also click the entry in Call Sites to go to the line.
2. If at any stage there is a function pointer assignment, Visual Studio loses track (code sample from open source Blender project):

ReSharper C++ call tracking fixes these problems and makes navigating the call hierarchy a breeze and you can follow the sequence up to main:

Visual Assist X, which is 70$ cheaper per license than ReSharper C++, does not have this feature, which is a deal breaker for me.

ReSharper C++ also helps with useful tips to modernize the code base. For more, see ReSharper C++ Quick Tips

ReSharper C++ all versions offline installers

Note that if instead of Visual Studio, you use CLion, it includes ReSharper features.

NetBeans "the type of ... is erroneous"

If your Java project builds successfully but NetBeans 8.2 shows red marks in code with the message "the type of ... is erronous", close NetBeans, clear all files inside 8.2 cache folder. On Windows the folder is located in %LOCALAPPDATA%/NetBeans/Cache/8.2

If this does not get rid of red marks, close NetBeans, open project.properties file, Delete any extra "}" at the end of javac.classpath section, e.g. it the final line in that section should not be ${reference.mylib}} but ${reference.mylib}. This usually happens when you manually edit the file.