Defendant wins breathalyzer source code

In your industry, perhaps. In the process control industry, availability of source code is often a requirement. It need not be open source. It may be licensed directly to the customer, or held in escrow by a third party.

--
Al Balmer
Sun City, AZ
Reply to
Al Balmer
Loading thread data ...

... snip ...

Well, considering that we separated in 1987, about 20 years ago, I have an excuse for not being up on their present status. I expect the systems have been largely retired.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

In this particular case, it seems that the contract explicitly called for all material which could be useful to a defendant.

--
Al Balmer
Sun City, AZ
Reply to
Al Balmer

If the case is marginal, the most important data for a defendant would be whether the math routines did any rounding in the calculations.

If the law says you're impaired at 0.08% blood alcohol level and the meter measured 0.07995%, then rounded up the display to 0.08%, the defendant would have a good case for dismissal.

You would think that the programmers who write that code would know about rounding problems, but you couldn't be sure until you saw the source code.

Mark Borgerson

Reply to
Mark Borgerson

That reminds me of a transputer based system I worked on some years ago. We had the choice of developing in Occam or C. The Occam development system would halt the entire system on an error such as overflow of an integer addition while the C version did not have that option. Of course your released system had the option of halting or not halting. But the point was if your processor was in a critical system such as flight control, would it be better to halt the system and report the error, or to continue to run using potentially corrupted data? Neither one is very desirable.

After talking to people in these fields, it seems to me the only possible way to handle an error like this is to halt the system and flag it as faulty. Humans can often work around a system failure as long as they are aware that it has failed. So it seems to me that it is only smart to have all run time checks enabled in the production system. If you don't have enough horsepower, get a bigger processor! Even in consumer products this can help reliability. I often have wished my router didn't reboot itself every day or two when used in certain modes. Likewise I have seen GPS units that came with "reset" buttons instead of On/Off buttons. Wouldn't it be better to trap the errors so they can ultimately be fixed?

Reply to
rickman

Yeah, like HDL is more complex than other software... HA!

Reply to
rickman

I hope you are never evaluating equipment for me! Anytime they check a radar gun it is under some "ideal" test conditions. Your speed was measured under real road conditions complete with multipath, multiple targets, interfering signals, etc...Heck, I was shown how they calibrate a radar gun once, they used a tuning fork to establish a timing reference for the final frequency measurement! Doesn't that completely ignore about 90% of the system???

Reply to
rickman

I don't think we have any philosophical disagreements :-)

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

Someone else has already mentioned Source code minus comments, and for a FPGA/CPLD there are various levels of 'source code'.

So there is scope for a 'high level of code obfuscation', and if someone wanted to avoid this, then it becomes an argument on when source code morphs into system design documents, and should someone be entitled to that as well ?

-jg

Reply to
Jim Granville

I don't follow you. What are the various levels of source code for an HDL?

Reply to
rickman

Take a trawl through the various report and working files of the tools. You'll see the design, but in different forms.

eg I have ported designs, using report files, as the 'source code'.

So, it rather depends on what you take "Source code" to mean - is it one file (enough to see how a portion works), or the full manufacturing build file set, which many would say, is much more than source. Are build scripts part of the Source code ? What about Simulation files ? Do comments constiture source ? - what about reduced boolean equations ?

With the latter, an experienced user compile, and get a working design.

-jg

Reply to
Jim Granville

Wow, so you would seize an engine, because one spark plug fails ?

Automotive makers, put a LOT of design effoer into what they call "Limp Home" mode, so I guess they have a different take on this :)

-jg

Reply to
Jim Granville

Different problem. In process control, for example, there are failsafe and backup control systems. Sometimes the safest thing to do is stop the computer and let the backup take over.

--
Al Balmer
Sun City, AZ
Reply to
Al Balmer

Do Automotive designs have the luxury of failsafe and backups, for all their systems ?

I'd imagine the failure profiles are dominated by the sensors/cables/battery, and not by the computer. ( I see ECC Flash is now fairly common in Automotive uC )

Another trend has been to multiple CAN ports on the larger controllers (when CAN was first promoted as a one-bus solution)

- again, I'd say that is failure-mode driven, and shows a fault-segmentation approach, rather than the HCF opcode approach (Halt and Catch Fire).

-jg

Reply to
Jim Granville

That's why I said it's a different problem, just as what rickman was talking about (and you replied to) is a different problem.

There are backups for some systems, btw. Power brakes and power steering come to mind.

--
Al Balmer
Sun City, AZ
Reply to
Al Balmer

... snip ...

Automobiles are not medical systems. We don't want to limp, once a failure has been detected it is high time to let the humans make the decisions (and take the blame). Limping left, instead of right, can easily cost a life.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

I design medical electronics and there we can have situations similar to the auto industry. If, for example, a sofware glitch occurs in an intravascular ultrasound system you better make sure it keeps limping on. Stopping while a stent is being placed in a complicated case could be like roaring down a mountain road in the dead of night and turning the headlights off.

For non-med readers: All this is handled via a hazard analysis. You identify all kinds of conceivable failures and for each there must be a severity rating (usually tied to the possible consequences), and a mitigation procedure.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

That's a different class to what I was doing. I was handling patient tests, such as Lytes, Glucose, etc. You have a much different situation.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

However, even if you discover a blatant flaw in a code or in the calibration (just as I did) the judge might still declare you guilty of speeding (just as he did with me). Ok, he was seriously thinking after I brought my findings to his attention but after five seconds of silence threw me in with all the others. Great.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Brings up another issue: What if your code partially executes on a math processor whose innards are under strict NDA, specifying the bullet size that shall be used if you reveal it? We had some of those, for example with certain scan conversion chips. IOW having the source code would not allow anyone to really determine things such as accuracy without the chip data, which they won't get.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.