Slashdot Mirror

Well SCADE does embedded DO-178b qualified model based development. I've used it in airplane hydraulic software. Not sure how it compares with Simulink though.

http://www.esterel-technologie...

There is also SCADE, used for safety-critical stuff such as avionics.

This is a pipe dream right now, but it doesn't have to be so. Software solutions that aid safety-critical development processes cost big bucks, same as training and really any sort of plain-language knowledge (standards aren't plain language). Compare this to the fact that, say, you can read on enterprise development best practices on many blogs, forums and documentation sites and it's free -- it's commodity. Try reading up something actionable on functional safety aspects of software development, ha ha -- at best you need $100 for one of Exida books just to get an overview of what's involved. Tools like Scade cost tens of thousands of USD per seat. Techniques and tools for developing reliable software will eventually become commodities, and as the knowledge hopefully permeates the industry, it will become a non-issue. It's like source revision control systems or parametric CAD systems -- once a big deal, right now they are either free (the former) or affordable (a couple hundred USD for a basic Alibre setup).

DO-178B OpenGL code generator for aviation.

It's the dreaded magic computer again, isn't it? Hopefully I can show that it's no magic, and that a lot of what you write is based on common misconceptions.

Saying "logging the data after it's been through the computer" is a strawman -- in a digital control system, all inputs and outputs are digital, and they are converted to/from analog signals. This is hardly a problem. The only way to log the data before it enters "the computer" is to, literally, get an analog tape recorder, or a chart recorder. There's no other way. A commonplace multitrack FM analog recorder weighs 100+ lb, and you may have problems fitting it on the passenger's seat. I have a few of those -- they use 1" tape, same as good old AMPEX helical scan video decks, and they are so bulky you need two people to move them.

The way the logging is likely to be implemented is quite simple. There will be a point in the control software where an input sample -- multiple channels' value from some time instant are in a nice vector. Quite likely a simple C struct of things. This vector is copied to a circular logging buffer, and the pointer is incremented. That's it. To save on logging space, the data may be decimated. That's about it. There can hardly be any "inaccuracies" in the logging application, unless it processes the data somehow -- perhaps they want to avoid aliasing in decimated data, and feed the data via a low-pass antialiasing filter. Of course if that filter is buggy, it'll corrupt the data, but that is rather easy to test for.

To detect subsequent data corruption in the log, each data sample may have a CRC attached to it when it's inserted into the buffer. That way you know that whatever is in the log is exactly what the digital controller saw.

Toyota is really using very non-technical speak when they "admit" that the recorder is not very robust. What they most likely mean is that because the data is stored in ECU's RAM, if you lose power the data will be lost. The ECU may have a supercap or somesuch to protect this RAM's contents during short power glitches, but that's about it.

To understand how it can all be rather so simple, you have to know how typical digital control software is designed. There is some input and output code, that collects data from various data sources (CAN bus, A/D converters, discrete inputs) and puts it into a nice input structure (think C struct or C++ class), and similarly takes the output structure and pushes the data out to the devices (CAN bus, D/A converters, discrete outputs). Those two parts can be well separated out, and usually are testable on their own. There may also be some networking and other housekeeping code that runs in the background, of course.

Then comes the actual digital controller, which maintains some internal state. The processing can be thought of as being done by a C function with following prototype (said function having only automatic variable declarations, and calling no other functions):

void controller(const struct Input_t * inputs, const struct State_t * input_state, struct Output_t * outputs, struct State_t * output_state);

The previous state (input_state) and inputs are processed, resulting in a new state (output_state) and outputs. There are frameworks for safety critical digital control (say ), and they use exactly that sort of an abstraction. The controller(...) function is typically generated C code, and the code generator has various guarantees as to it being accurate (bug-free). The input and output glue code is simpler, and typically separately tested.

To say that there are "issue with the computer" then is just meaningless. If the computer hardware has problems, they will likely affect everything, and would be likely to result in a "crash", and the watchdog will do an automated reboot. The computer software can have many types of problems, and they can be squarely separated into two areas: the controller(...) function, and everything else -- we'll call it Housekeeping

Synchronous and deterministic languages such as SCADE permit to drastically reduce the number of bugs. As a former C/C++/java developer, I can tell you these tools are really ideal to develop safety critical sofware. And the code generator is DO-178B qualifiable up to level A, one of the most stringent certifications for embedded software in for civilian avionics, thus allowing you to certify the SCADE language and forget about low level testing on the generated C code. This tool is massively deployed at Airbus (A340 and A380). It is used for many other planes/helicopters

Synchronous and deterministic languages such as SCADE permit to drastically reduce the number of bugs. As a former C/C++/java developer, I can tell you these tools are really ideal to develop safety critical sofware. And the code generator is DO-178B qualifiable up to level A, one of the most stringent certifications for embedded software in for civilian avionics, thus allowing you to certify the SCADE language and forget about low level testing on the generated C code. This tool is massively deployed at Airbus (A340 and A380). It is used for many other planes/helicopters