Please downloadPlease download images to give correct formatting OR Click here for on-line graphical version
Phaedsys Banner
Cost effective Safety Critical and High Reliability Embedded Systems Tools
| Get rid of Bugs| Software eats the Project | What is programming? | Failed Project |
| Go Forth and....| Toyota again | AI insurance | GDPR | IoT insecurity | RTOS size |
| it's embedded world again ! l| 
Visit us online
Welcome to Spring – we hope.
 
This March was one of the wettest on record, and April seems to be trying hard to emulate it. Interestingly the weather in Nuremberg for embedded world was dry and sunny, and very cold.
 
The embedded world event continues to grow and it was an opportunity to catch up with old friends and make new ones. I won't name drop but virtually every "name" in our world was there also a few people whose names you won't immediately know but their companies you will.
 
The random networking is great. By chance I found myself chatting with a VP of Intel one evening. On the up side there were more Brits visiting you should go in 2019 whilst you can without needing a visa!
PhaedruS SystemS
Get rid of more bugs in 2018
 Members of the stamp out bugs in 2018 group were at embedded world. Michael Bar and his team were talking about their Embedded Systems Safety & Security Survey. Check it out at  https://barrgroup.com/embedded-systems/surveys/2018  but it is not comforting reading if you are concerned with the overall health of the embedded system industry.
 
You will find that as 2018 progresses more people will be stamping out bugs in software by more correctly referring to them as errors or defects.
 
However not all SW "bugs" are programming errors and this also needs to be addressed. Some "software bugs" are in fact errors in design or requirements and not programming errors. 
Killer Cars?
We are still waiting for an in-depth technical report on the Uber fatality, but that hasn't stopped all sorts of people, some less than well informed, from commenting on this incident and autonomous cars in general. Surprisingly the published videos of the crash do not tell you enough to make a judgement without additional information.
 
We are getting the impression that Uber might have cut some corners in an attempt to stay ahead of rival firm Waymo, but it will be some time yet before we know if that was the case or if the corners cut (if any) were significant.
 
What we will see is a barrage of law suits. So keep your heads down!
Brain Waves
As if autonomous cars were not creepy enough, it looks as though Nissan is working to have your mind control the car, without any physical interaction. 
 
Requirements
How do you know if you have built what is needed if you haven't drawn up a list of requirements? More to the point how can you test it if you don't have requirements to test against?
 
Jack Ganssle in an article in a recent issue
 (http://www.ganssle.com/tem/tem343.html#article3) of The Em-bedded Muse looks at the characteristics of a well-thought-out requirement drawn from Leanna Rierson's book Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance.
 
Combine these with Visure Requirements
http://phaedsys.com/principals/visure/visure.html   and your project is off to a good start.
 
You should remember the words of Watts Humphrey in 2005 when he said" The PSP data show that, for every defect type and every language measured, defect-repair costs are highest in testing and during customer use, Anyone who seeks to reduce development cost or time must focus on preventing or removing every possible defect before they start testing."
 
The very important part of that quote is "the data show that". It is not just opinion it is a measured reality. If you want to save time and money keep the errors out. I have personal experience of doing this on projects.
Fire code for software
In another article (http://www.ganssle.com/tem/tem345.html#article2 ) Jack wrote about the long time it took for the United States to develop and enforce a code of practice for buildings, despite the huge loss of life caused annually by fire and compared Fire Code's (regulations) for buildings to the issues in software.  
 
This theme was picked up by the Bielefeld System Safety Mailing List. As with all mailing lists, the conversation went in all sorts of directions but you may find it worth a little time to read some of it. The thread starts at http://www.systemsafetylist.org/3611.htm.  
 
Anyone developing critical or high reliability systems needs to read the Bieleleld list   Though following on from the Watts Humphreys quote above that might want to include anyone who wants to produce software quickly and inexpensively! 
 
There was a follow-up to the original piece in the next issue of Jack's newsletter.
 http://www.ganssle.com/tem/tem346.html#article4    Again this al comes back to keeping  the errors out of software.
 
Rail Fail
Last autumn a train driver on the Cambrian Coast Line realised that the in-cab display wasn't displaying temporary speed restrictions, a potentially very serious issue.
 
The Line is running a pilot installation of the European Rail Traffic Management System (ERTMS) which transmits data directly to the train, where information, such as temporary and permanent speed restrictions is displayed on a screen in front of the driver.
 
The system had been routinely restarted the previous night but then failed to send any speed restriction information. The Rail Accident Investigation Branch (RAIB) is investigating what happened.
Safety and the Law
We have mentioned before that The Corporate Manslaughter and Corporate Homicide Act means that organisations can now be held liable for "serious management failures resulting in a gross breach of a duty of care."
 
Martin Allen, in a tongue-in-cheek posting, looks at a possible court scenario at https://www.linkedin.com/pulse/safety-law-martin-allen/ 
 
For a less humorous but equally thought provoking read try The Corporate Manslaughter and Corporate Homicide Act  you can download it here.    ukpga_20070019_en.pdf  and the notes for "understanding" it  here manslaughterhomicideact07.pdf
 
Drop them on your managers desk next time s/he  suggests cutting corners..... 
Snooping home?
Kashmir Hill, a reporter for Gizmodo, converted her apartment in San Francisco into a smart home, connecting as many appliances and belongings as she could to the Internet. The objective was to measure what information the smart devices were passing along. And it was a lot. But as a side effect, the process of setting up and then living with these devices was frustrating and time-consuming.
 
The full report is here https://gizmodo.com/the-house-that-spied-on-me-1822429852 , and thanks to Bruce Schneir's CRYPTO-GRAM https://www.schneier.com/crypto-gram.html  for the link. Xkcd (the web comic of romance, sarcasm, math and language) has its own take on the same topic at https://xkcd.com/1966/  
Laughing Alexa
Apparently, Alexa has a "quirk" which cause her to randomly laugh. https://www.usatoday.com/story/tech/2018/03/07/alexas-weird-random-laughter-freaking-people-out/404476002/ It is worrying that a product deployed in massive quantities has unintentional behaviour. At least this unintentional behaviour is noticeable. What if other unintentional behaviour is not so you have no idea what it is doing when…
 
Also it is not just Alexa.... there are very many IoT things people are putting into their homes. Some work well together (and securely) but other less well and a lot less securely.  DO you know which is which?  
 
Now the serious bit: what will insurance companies do when people claim on home insurance for problems caused by IoT products.  Are you liable?   The shop you bought it from?  BTW "on-line" might be anywhere and is probably "somewhere else" or the manufacture if you can actually work out who that is....
Quote Quorner
"We are just an advanced breed of monkeys on a minor planet of a very average star. But we can understand the Universe. That makes us something very special."
Stephen Hawking
Stephen  was actually one of the very  few who really did understand the universe. That makes him special. RIP
 
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks (this is still a universal constant)
 
"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."
Andrew S. Tanenbaum: Computer Networks
Replacing tape with SSD's this method is still faster than commercial broadband in some parts of the world!
 
 "1. Good enough is good enough.
 2. Good enough always beats perfect.
3. The really hard part is determining what is good enough."
Ravi Sandhu
Product news Tracealyzer 4
Tracealyzer 4 is available. The new release provides lots more functionality and is rolling out across multiple RTOS families. If you need a simple introduction to what an RTOS viewer can provide there is a manager-friendly video at https://www.youtube.com/watch?v=ysiuQUbf7mY&feature=youtu.be  
Bugs in history
We all know it was Grace Hopper's team at Harvard in 1947 who introduced the term bug into electronics. Well we are all wrong. It was Thomas Edison over 70 years earlier in 1873. The full story is here: http://theinstitute.ieee.org/tech-history/technology-history/did-you-know-edison-coined-the-term-bug But in both cases, these were genuine issues, and not a synonym for a programmer's error.
Software engineering with Cats
Comic site Sandraandwoo.com  never understood why a swing was used as a guide to how a software project evolved, so decided to use cats instead. See the result at http://www.sandraandwoo.com/2012/11/19/0430-software-engineering-now-with-cats/
Medical shocker
 Mentor (now we have to say Mentor: A Siemen's Business) has a white paper "The future of medical device certification" http://go.mentor.com/4guvn .

The company says "The FDA reports that 75% of medical devices submitted for regulatory approval fail on the first attempt, resulting in product release delays and costing companies money in redesign and lost opportunity."

One of the main points is the need for a full-featured certified RTOS framework.  However much of the white paper is relevant to any safety-critical project.
Wise plumbers
An article on enterprise software has lessons for embedded systems. Not all the ten rules espoused in https://www.zdnet.com/article/10-rules-of-software-design/  are relevant, and I am wary of anything that publishes a manifesto, but the main argument is that we should move from an approach of "Move Fast and Break Things" to "move slowly and fix things".
The problem is summed up by a plumber faced with a complicated set of pipes:
"They didn't keep things simple you see, they let it get complicated. Now we're spending ages trying to figure out what's going on. If it were simple, I could just glance at it and I'd know. But there's a pipe back there that goes up, along, back down, and connects to itself. I have no idea why on earth that's there but I can't take it out in case it's important."
 
Spaghetti plumbing?
A rather long newsletter this time. We are going to get back to shorter ones a little more often (6 weeks not 2 months). With some longer articles on a linked to blog that will explore some topics a bit deeper.
 
In the meantime it's an ERROR not a bug. However not all of the "software bugs" are programmers errors. Many are dubious design and requirements. If we can improve the programing part of development we can separate the coding errors from the design errors and shift some of the blame back where it belongs.
Forward this email
Forward
 
Tel: 0808 1800 358Email usVisit us online
PhaedruS SystemS Ltd, 96 Brambling, Tamworth, Staffs, B77 5PG, UK
Registered in England with Company Number 04120771
learn more about  newzapp email marketing This message was sent to chrisg5@phaedsys.com by PhaedruS SystemS Ltd using newzapp email marketing. Follow this link to .