Leveling out

The terms High level and low level control refer the abstraction and application specific nature of the control. A good explanation of high and low-level is: Suppose one has a really obedient person, who you had to direct around a short maze. A low level approach might be: Put your right foot in front of your left (and instructions to keep balanced) then the other and then turn… with all the details included. Now, that’s pretty tricky from far off, especially if one has to shout it at people (slow). The next approach would be: Walk forward 10 steps, turn left…etc. Or even higher, walk to the next turning and turn left. Or the highest level of them all: Navigate the maze.

Say now it was something that flew. The lowest level just wouldn’t work, the next, the units would have to be converted, the next, might work but probably wouldn’t be that idea, however the highest: the thing might simply just fly over it, however it would “navigate” the maze. Simple!

Of course it gives you much less fine control over speed or route or remembering or anything, and requires a lot of work on the part of the addressed thing.

Software constructs like operating systems and drivers are designed to give the developer, and in the end the user, a higher level approach. It makes all file systems look the same to the program: Whether external memory cards or the built in hard disk, makes a printer look like a printer not a specific model. That is the genius of modern computing.

Of course the operating system approach is a software leveling up, and there are potentially other ways of doing such things, such as segmented hardware.

By segmented hardware I mean having external hardware which takes the specifics of the interface or driving away from the main controller. Although this takes away potentially even more control possibility from the user program, it also means that already stressed processors have fewer overheads. Here’s an example:

Say one is building an autopilot (which flies a plane) and you want it to have quite sophisticated behaviour built in: able to do stunts, cool dynamic calculations or some such. But to control the physical hardware, one needs to send servo control signals, which are made up of 1 pulse of a variable length at about 200Hz. Now say for every pulse one has to set up a interrupt routine (a part of code which is called periodically, on a pin change or on another system event), which would be called at 8(channels) times 200 a second => 1600Hz. Say you clock your main processor at 160MHz, a pretty fast micro-processor. Then you would end up having an interrupt every 100 instructions: Which, especially when combined with operating system overheads, really cut up ones flow.

If one had a pretty dumb micro (or even logic system/FPGA) one could offload all of that time dependant stuff onto it, leaving cleaner code and easier writing to the hardware. Also, if one wanted to change all of the servos for ones which take a different input, all it would require is a change of the auxiliary system, not the main source code, much like a change of drivers in a software model.

Although on a higher performance system, the overheads and problems caused by drivers and interrupts start to diminish, on lower performance systems it really does matter and especially as it will messy the code used. Problems such as this are amplified on systems with no operating systems. Sometimes, although the added complexity of an interface, the neatness and verifiable nature of separate blocks of hardware can pay off, especially as it will not fail if the main system locks up. Prehaps something worth considering…


A life for a battery

Quite a lot of the tubes are buzzing with a hackers observation that, given some specialist hardware and knowledge, hacking a wireless insulin pump would be pretty easy, in fact so much so, it could be done from a full half a mile. On doing a little more reading, it quickly becomes apparent that that kind of meter has no encryption in its link. None.

Now I use data radios quite a bit, and pretty much all of them worth speaking about have AES128, which means it has 128 bits of crypt, meaning there are 2^128 different possible codes, meaning if one tried a new code at 1 MHz (about as fast as it would be possible, even with some really custom and flashy hardware), one would take 10 septillion (that number actually exists) years to test every possibility.

Say ones data was being sent every minute, as a glucose meter probably would, that would mean that one simply would not get enough data over an hour to crack AES128, let alone AES256. And why don’t the manufactures do it? (other than its not required, and they aren’t massively incentiveised to do it) Because more hardware = more power used. Now, I’m not sure about most people, but if I had to change my insulin pump/monitors batteries 1.5 times more often (its only a tiny bit of extra silicon running), I probably wouldn’t notice, whereas if someone hacked my pump, I think I would, too late.

Now AES128 might even be a bit extreme, so lets review the points:

  • Car keys are hardly ever cracked, even if you have the key and the car and you hit the button thousands of time, they have a rolling code etc and are really really hard to crack. Oh wait, they run on batteries… forever…
  • One has to establish a private key at some point, so that would have to be done carefully (a la bluetooth) or with a physical interface (a little cable or something) at setup. Setup of connection can often be a weak point.
  • If the interfaces were two way, and required checking or acknowledgement, or even *any* scheme like that, the distance at which one could play that game would be extremely limited (10m?).
  • What happened to charging?

The real main problem is that, sure now we know that people have thought of hacking into them, but I’m sure that the management who designed the block diagram of the whole system didn’t go “wow, I bet someone will try and hack this”, because people never think like that. Now, prehaps it will be put into new designs (good sales “gimic”), but thats where the major problem lies.

Products specified for medical purposes have to go through thousands of hours of testing, verification and error finding (as you would expect) which can cost huge quantities of money and, more relevantly, take years. On top of this getting approval from the right medical bodies would would also take a couple of years. This means that any new devices with the encryption built in would take at least 2 years to surface, and all those already in verification would all be released in the mean time would be useless.

The only thing that would actually push companies to change their designs would be to only grant new approvals to products which include enough digital safety systems. Sure this would be unpopular with the companies who make such things, but otherwise we’ll face a few years of new pumps and new medical systems going out completely un-protected.

It seems ridiculous that this kind of thing isn’t well covered somewhere in the medical spec, but I guess thats the kind of unjoined up thinking that the world suffers. Again the hackers have probably saved and condemned lives and business.

Hierarchical Systems Design

I doubt many people have heard of the “Celtx” software suite, but it really is the most amazing bit of pre-production software I could think of. Why so?

  • Its free, whats not to like?
  • It has its own text editor especially for writing scripts
  • Names in this text editor are linked to characters
  • Characters have their own bio
  • And everything can be linked to files
  • Including animals or makeup artists

Basically its a really rich environment where everything is about linking all the parts of film or stage productions so one can easily see whats to be done. It even has its own drawing suite for basic scene layout!

It really does make starting ideas for films a doodle (not that I do that often, but its still an awesome bit of software I play with occasionally).

How does this have anything to do with the title? Well I find myself these days turning out quite a few block diagrams for various projects, so I can see what kind of things are required in the project planned. At the moment I use “dia” (well technically dia portable), a not very glamorous but perfectly functional bit of open source software which allows the quick and easy creation of most block/flow diagrams, but it lacks the deep down functionality I really want: it isn’t a system design package.

Some blend of block/flow diagrams and a celtx like integration of bits would make designing high (to mid) level diagrams and systems much simpler. The work flow would go something like this:

  1. Create new project, name etc. IE a car’s electronics
  2. Start with a top level (starting with the aim not the process) diagram with the large blocks in the system. IE The engine management, the media system, the heating system, the driver
  3. Linking the blocks with various interfaces (including interfaces one could name and type, radio/wireless technologies could have their own icons and colours). IE: CAN to join most of it, bluetooth to the persons phone
  4. Breaking into one of the blocks to define its makeup at a lower level. IE: the engine management
  5. Possibly breaking down into another layer of detail IE: the input part of the engine management
  6. Attaching schematics, code, datasheets, comparison tables, reports to any of the blocks.
  7. Attaching and designing flow diagrams of the system block.
  8. Going back out to the first top level view and doing another block

Such an approach lets the user fill outs bits they know at the start, leaving the rest up to others or at least delayed until further research is done, without loosing the scope of the entire project.

Such a piece of software would hardly be that difficult, or that radical. One would have to be careful to leave it as general as possible (like dia) as to serve as many people as possible.

Finally, if anyone would like to help me find/make this software, I would be happy to help, although an open source license is a must. Or if anyone already knows software which does this…

The state problem

During a recent programming frenzy I came across the problem of mode definition. For many embedded systems one needs to know many bits of information about the current state, the boot success, programmed modes etc, some of this only becoming apparent some way through programming or developing the system. To add complication, many of the states are interconnected to a point where, unless care is taken, they fragment into meaningless and pointless values.

Say one has a project which interfaces with a couple of pieces of external hardware including one units which provides a major bottle neck in the data flow, say a flash disk. The other devices have boot up checks which allow failures to be reported. The device can clearly be in a multitude of modes, all tied, some meaning the whole system cannot run and some meaning UI elements should be running…
The way one might start defining all the possible modes as values of a integer (say 1 being running etc) and this serves well up to a certain point… but when you start to switch functions off the mode values you can end up with some pretty long conditional statements.

Say one can take a memory detection failure as long as the device does not try to access the memory card later in the program. This masks some functions of the project, obviously. How would one store that the start-up sequence had failed to recognise the memory? Say one stored the memory access state in one variable, with 0 being fail, 1 being working or something like that, what happens when the program or the user tries to access the should-be-blocked functions? Does the program have to check the entire array of settings to see if it can run each time? How about if there are two memory devices, say a card and inbuilt and either can be used…One can see the whole situation getting out of control.

This doesn’t even start to cover all the problems with function modes, low battery checks, indicators, UIs… The whole thing seems to be a network of interconnected crud, needing to be interpreted without lots of faffy code for the programmer to wade through when he finds a problem.

In a perfect world what one really needs to do is to write a big tree diagram of all the modes one could be in, of all the different things that have state variables attached to them, the implications of each outcome etc. Then one could go about designing the system in a way that would be structured top down, with the layout already defined and thought through. This of course is very difficult to do in short turn around programming where the project evolves as time goes on. One might wish to add features in the future or be able to program little bits in quickly that have strange case sets.

There is only one really logical choice for expandable and serviceable (and of course readable) programming: like always, modularise (reminds me of the Tom Lehrer song “plagiarise”..). Make all the settings bits and pieces into one big class or plain library (classes are always prettier and more wrapped up (also sometimes useful to be able to separate them)) and write accessors functions which contain all the interlink decisions. When it comes to realising that the thing really cant run this without memory, you only have to edit one thing in the library (in a known location) and you’re done! Sounds simple.. Need to know if you can run a segment? write a function which is boolean returning: say: mode.canLog(); returns true if the memory and other requirements are there, false if not… Just like how you might write the if statement if you were coding it in but a lot easier to read. This modularisation is good practice in any programming but this method seems particularly useful and maybe less immediately obvious ( or obviously beneficial) but I’m sure that it will save loads of time later… Also classes are brilliant! (forgive my enthusiasm)…

I have always found problems in convoluted state variables and the interconnects are often mind blowing however I think that it should be reasonably simple to sort out if it was all in one place….

That’s my tuppence on that subject, I hoped it helped someone! Comment and share!

%d bloggers like this: