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
| Wet String | C vs Forth | Hacking Airliners | ew Tickets | Phone bugging |
!Clients from Hell | Sile Rule Simulator  | 
Visit us online
A belated welcome to 2018, which at the macro/governmental level promises to be an interesting time what with GDPR and Brexit. Also we have the march of the autonomous vehicles, Data security (or lack of), and the new iPhone (well the old one is 6 months on now)!  
 
However, I and a number of other commentators are determined that 2018 is the year when we see the end of bugs.
PhaedruS SystemS
Get rid of bugs in 2018
As we discussed in the last newsletter (Click this link here), quoting Dijkstra, calling a problem a bug hides the fact that it is usually a mistake or an error.  We need in a shift in the attitude to "bugs" in software before the insurance companies and lawyers get involved, and they are starting to get involved already.
 
Better we address the bug problem ourselves than have The Suits and Spreadsheet Warriors do it for us. The solution is in our own hands  (and has been for several decades)
 
Read on in the blog article  as to how to remove "bugs" and have more reliable systems at and spend less money doing it!  You can't buy your way out of this one! click here on how to remove all bugs from software. click here
 
Software eats the project 
Jack Ganssles' The Embedded Muse
( www.ganssle.com/tem/tem341.html ) has some results from analyst company VDC's survey of embedded development.
 
It is worth looking at the longer article, but among the highlights are that software is 34% of the time of a project, but even then, "In the first year after a product is shipped:
 
the average number of bugs discovered is 67. The median is 5, so some seriously-buggy code is out there.
 
The mean time to fix each bug is 45 hours, with a median of 30 hours. (that is a person-week per bug )
 
That's interesting, as it lends credence to the observation that bug fixes cost orders of magnitude more in the field than in development." Another interesting element is that ARM Cortex is now the dominant architecture being use in 57% of the projects. But do go and look, www.ganssle.com/tem/tem341.html
 
You may also want to see Jack's stance on the bug/error debate. 
 
What is programming?
The word error turned up in reports of the loss of satellites that were in a Russian rocket launch.  The Guardian
 ( https://www.theguardian.com/world/2017/dec/28/russian-satellite-lost-wrong-spaceport-meteor-m  ) reported "Russian deputy prime minister Dmitry Rogozin said on Wednesday the loss of a 2.6bn-rouble ($45m) satellite launched last month was due to an embarrassing programming error."
 
What he meant was that the coordinates of the wrong launch site were entered into the system. It is as though you entered the wrong post code into your in-car navigation system and blamed getting lost on "a programming error" rather than operator error.
Project failed – dump the files?
IMAGE - a US satellite, appeared to die in 2005. That is a mere 12 years ago.
 
Last month and amateur astronomer found that it was transmitting, and after a short period NASA agreed, but said that , to quote the Register ( https://www.theregister.co.uk/2018/01/30/zombie_satellite_is_image/ ) "it [NASA] doesn't have the electronics and software to hand that are compatible with whatever the bird is transmitting and expecting to receive." 
 
 NASA actually said, "The types of hardware and operating systems used in the IMAGE Mission Operations Centre no longer exist, and other systems have been updated several versions beyond what they were at the time." 
 
Rather sad that the satellite was faithfully doing its job and no one was listening. But the bigger lesson is that you retain earlier versions of software and its documentation and there are version control tools that allow you to do just that.
 
Last year Phaedrus Systems was ask to supply hardware Ice for an MCU that went obsolete before IMAGE stopped working. We were able to do that. We have contacts that can usually find most hardware and software from the last 20 years  See our paper on handling obsolescence
 
Yesterday I was talking to a client:  They have a control system installed in 1993 and the HW programmer for it.  What they didn't buy was the £10 cable to connect the programmer to the PC! They are currently looking round eBay for one and trying to put together a PC that will run Win3.1 
 
5 million people rely on this system every day and the lack of a £10 cable and the archiving of a Win3.1 PC...  Even Shakespeare and his horse knew this problem 100's of years ago.  Phaedsys can, of course, find not only the hardware but have located a suitably qualified programmer for the equipment.
 
Go Forth and...
Forth is an interesting language and has a vibrant (and sometimes abrasive) community. A set of IAQs (Infrequently Asked Questions) about Forth and C by Howerd Oakford is at http://www.inventio.co.uk/forthvsc.htm . Oakford is a Forth enthusiast, and while I don't agree with everything he says It is worth a look. As he says at the end "If your only tool is a hammer, all problems become nails", particularly if you don't know other tools exist. monthly
 
Incidentally the Euro Forth conference this year marks the 50th anniversary of the invention of Forth and will be held in the UK.  It is rumoured the  inventor of Forth may be attending.  Email us for more details as they become available!!
 
Unintended acceleration argument
You all know that in 2013 a court found that Toyota's software was responsible for a death caused by unintended acceleration. In December an article appeared in Embedded Computing ( https://www.embedded.com/electronics-blogs/say-what-/4459136/Why-every-embedded-software-developer-should-care-about-the-Toyota-verdict ) that criticised the expert witnesses whose evidence was a major factor in the case.
 
It is fair to say that Michael Cummings, the author, didn't hold back on his attack on Philip Koopman and Michael Barr. Koopman responded. The comment trails beneath the articles are extensive and in some cases quite unpleasant. Surprisingly I found myself quoted! 
Insure your connected/autonomous vehicle
A conference in America is going to be looking at how insurance companies are going to deal with information they receive from connected cars. From the flier "Once data arrives at the insurance company, how is it being put to use …
 
• To help profile drivers, without being discriminatory?
• To help present personas who are better risk than others?
• To develop a robust underwriting engine?
• To adjust & settle claims faster while lowering claims dollars?
• For driver training, and improved customer retention?
• To make mobility safer and smarter?"
 
Yes the Lawyers and Insurance companies will be working out who is liable and who will end up in court.....  I refer you to the item above about the Toyota (also the  VW case) where the software ended up in court. You may have to explain your code to expert witnesses and a jury (and I doubt changing jobs will save you) .
GDPR
Closer to home, the General Data Protection Regulation (GDPR) will apply from 25th May, so you should be making sure that your organisation is compliant. It requires you to look very carefully at how you handle personal data. If you hold any personal data, its protection is not an IT issue, but requires decisions by senior management since the GDPR covers the use made of the information.
IoT insecurity
Brian Krebs has listed some common sense "Basic Rules for Securing Your IoT Stuff"
( https://krebsonsecurity.com/2018/01/some-basic-rules-for-securing-your-iot-stuff/ ) It is aimed at the end user, and includes things such as only connect to the Internet through a firewall, and change default credentials (if you can) and so on.

Sadly the "if you can" element is more frequent than you would like, given the poor documentation that arrives with much IoT equipment.
My RTOS is smaller than yours
Colin Walls, of Mentor Graphics (now a Siemens company) is an experienced and thoughtful commentator on the embedded scene. In a blog on the RTOS memory footprint ( https://www10.edacafe.com/blogs/embeddedsoftware/2018/01/15/rtos-memory-footprint/ ) he discusses the difficulties in calculating how much memory (both ROM and RAM) your RTOS will need.

He is talking mainly about Nucleus (though the numbers are similar for most RTOS)  and he says "Nucleus RTOS running on a typical embedded CPU yields a ROM size of 12-30 K and RAM of 500 bytes. The low-end ROM size includes the essential services; the high value includes all services. The runtime library is excluded."
 
This is just for the RTOS and does not allow for services (TCP/IP etc) or applications. though again most TCP/IP, USB CAN etc stacks are of similar size from most vendors. The problem is that the number of connections, buffer sizes etc means that there is no fixed size for them. 
 
In my experience this is not a bad estimation for many RTOSs but, if you are going to use Linux, this is a this is a massive understatement. I found one person saying  a minimum of 700KB. Though a minimum bootable system is over 2MB (but again this would include various stacks, drivers & file system). Also of course Linux is not Real Time in the same way that the small RTOS are.   Horses for Courses I think.
embedded world
It's February, so it's time to consider visiting embedded world in Nuremberg. Opening on February 27th it is three days dedicated to all things embedded.
 
Last year there were just over 1,000 exhibitors and 30,000 visitors. Tickets for the exhibition can be download at no charge from https://www.embedded-world.de/en/visitors/tickets/voucher  and enter ew18StD.
 
I will be there and if you are going, drop me a note and we might meet up. There are plenty of places for a quick beer and a gossip. Of course being Germany even the cafes in the exhibition have beer...
Well that is the start of another year. A lot of changes on the horizon: Lawyers and insurance companies will be looking at YOUR code at some point so it is time we faced reality and called "bugs" "errors" now and sorting them before you have to do it in court.
 
Whilst you may not think you are working on a critical system with almost everything now connected to everything you could end up in court as the weak link that was the gateway into something else. And I forgot…
 
There is also Brexit to contend with. Fortunately we should not need visas for Embedded World in Feb 2019
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 .