How to make your embedded C code immune to requirement changes without adding too much overhead and complexity?

Question

In many embedded applications there is a tradeoff between making the code very efficient or isolating the code from the specific system configuration to be immune to changing requirements.

What kinds of C constructs do you usually employ to achieve the best of both worlds (flexibility and reconfigurabilty without losing efficiency)?

If you have the time, please read on to see exactly what I am talking about.

When I was developing embedded SW for airbag controllers, we had the problem that we had to change some parts of the code every time the customer changed their mind regarding the specific requirements. For example, the combination of conditions and events that would trigger the airbag deployment changed every couple weeks during development. We hated to change that piece of code so often.

At that time, I attended the Embedded Systems Conference and heard a brilliant presentation by Stephen Mellor called "Coping with changing requirements". You can read the paper here (they make you sign-up but it's free).

The main idea of this was to implement the core behavior in your code but configure the specific details in the form of data. The data is something you can change easily and it can even be programmable in EEPROM or a different section of flash.

This idea sounded great to solve our problem. I shared this with my colleague and we immediately started reworking some of the SW modules.

When trying to use this idea in our coding, we encountered some difficulty in the actual implementation. Our code constructs got terribly heavy and complex for a constrained embedded system.

To illustrate this I will elaborate on the example I mentioned above. Instead of having a a bunch of if-statements to decide if the combination of inputs was in a state that required an airbag deployment, we changed to a big table of tables. Some of the conditions were not trivial, so we used a lot of function pointers to be able to call lots of little helper functions which somehow resolved some of the conditions. We had several levels of indirection and everything became hard to understand. To make a long story short, we ended up using a lot of memory, runtime and code complexity. Debugging the thing was not straightforward either. The boss made us change some things back because the modules were getting too heavy (and he was maybe right!).

PS: There is a similar question in SO but it looks like the focus is different. Adapting to meet changing business requirements?

Answer 1

Our system is subdivided into many components, with exposed configuration and test points. There is a configuration file that is read at start-up that actually helps us instantiate components, attach them to each other, and configure their behavior.

It's very OO-like, in C, with the occasional hack to implement something like inheritance.

In the defense/avionics world software upgrades are very strictly controlled, and you can't just upgrade SW to fix issues... however, for some bizarre reason you can update a configuration file without a major fight. So it's been darn useful for us to be able to specify a lot of our implementation in those configuration files.

There is no magic, just good separation of concerns when designing the system and a bit of foresight on the part of the developers.

Answer 2

As another point of view on changing requirements ... requirements go into building the code. So why not take a meta-approach to this:

1. Separate out parts of the program that are likely to change
2. Create a script that will glue parts of source together

This way you are maintaining compatible logic-building blocks in C ... and then sticking those compatible parts together at the end:

/* {conditions_for_airbag_placeholder} */
if( require_deployment)
     trigger_gas_release()

Then maintain independent conditions:

/* VAG Condition */
if( poll_vag_collision_event() )
    require_deployment=1

and another

/* Ford Conditions */
if( ford_interrupt( FRONT_NEARSIDE_COLLISION )) 
    require_deploymen=1

Your build script could look like:

BUILD airbag_deployment_logic.c WITH vag_events
TEST airbag_deployment_blob WITH vag_event_emitter

Thinking outloud really. This way you get a tight binary blob without reading in config. This is sort of like using overlays http://en.wikipedia.org/wiki/Overlay_(programming) but doing it at compile-time.

Answer 3

Hooking in a dynamic language can be a lifesaver, if you've got the memory and processor power for it.

Have the C talk to the hardware, and then pass up a known set of events to a language like Lua. Have the Lua script parse the event and callback to the appropriate C function(s).

Once you've got your C code running well, you won't have to touch it again unless the hardware changes. All of the business logic becomes part of the script, which in my opinion is a lot easier to create, modify and maintain.

Answer 4

I suppose what you could do is to specify several valid behaviors based on a byte or word of data that you could fetch from EEPROM or an I/O port if necessary and then create generic code to handle all possible events described by those bytes.

For instance, if you had a byte that specified the requirements for releasing the airbag it could be something like:

Bit 0: Rear collision

Bit 1: Speed above 55mph (bonus points for generalizing the speed value!)

Bit 2: passenger in car

...

Etc

Then you pull in another byte that says what events happened and compare the two. If they're the same, execute your command, if not, don't.

Answer 5

What are you trying to save exactly? Effort of code re-work? The red tape of a software version release?

It's possible that changing the code is reasonably straight-forward, and quite possibly easier than changing data in tables. Moving your often-changing logic from code to data is only helpful if, for some reason, it's less effort to modify data rather than code. That might be true if the changes are better expressed in a data form (e.g. numeric parameters stored in EEPROM). Or it might be true if the customer's requests make it necessary to release a new version of software, and a new software version is a costly procedure to build (lots of paperwork, or perhaps OTP chips burned by the chip maker).

Modularity is very good principle for these sort of things. Sounds as though you're already doing it to some degree. It's good to aim to isolate the often-changing code to as small an area as possible, and try to keep the rest of the code ("helper" functions) separate (modular) and as stable as possible.

Answer 6

For adapting to changing requirements I would concentrate on making the code modular and easy to change, e.g. by using macros or inline functions for parameters which are likely to change.

W.r.t. a configuration which can be changed independently from the code, I would hope that the parameters which are reconfigurable are specified in the requirements, too. Especially for safety-critical stuff like airbag controllers.

Answer 7

I don't make the code immune to requirements changes per se, but I always tag a section of code that implements a requirement by putting a unique string in a comment. With the requirements tags in place, I can easily search for that code when the requirement needs a change. This practice also satisfies a CMMI process.

For example, in the requirements document:

The following is a list of requirements related to the RST:

• [RST001] Juliet SHALL start the RST with 5 minute delay when the ignition is turned OFF.

And in the code:

/* Delay for RST when ignition is turned off [RST001] */
#define IGN_OFF_RST_DELAY 5

...snip...

                        /* Start RST with designated delay [RST001] */
                        if (IS_ROMEO_ON())
                        {
                            rst_set_timer(IGN_OFF_RST_DELAY);
                        }