NASA Goddard Space Flight Center (GSFC) Software Assurance

Back in the blog I wrote, The Anatomy of a Race Condition: Toyota vs AVR XMega I mentioned the NASA Software Safety Guidebook. Seems that link went viral, as it popped up lots of other places the next day as people spread it around.

I was a bit surprised, but glad, to find that the Software Safety site and this Software Safety blog are listed number one and number two by SEMRush (a 'Competitor Research Service'), beating out NASA themselves at number four, for the term "Software Safety".

Will today's link to NASA's Goddard Space Flight Center's Software Assurance page go viral as well?

"The NASA Goddard Space Flight Center (GSFC) Software Assurance Website provides tools, procedures and training materials for software and safety assurance personnel, software engineers, as well as program and project managers."

Of the most practical day to day value are the numerous Checklists, for example one on Code Inspections, and the Forms and Templates. There are also examples of Procedures, Guidelines, Work Instructions, links to tools etc. The Automated Requirement Measurement (ARM) Tool has been developed as aid to "writing the requirements right," not "writing the right requirements". As of this moment Humans still create the initial requirements for any device or Embedded System, and Humans are prone to errors. Unless an other Human catches the error(s) in a requirement document early in the development life cycle, no downstream tool will clean up the mess or mitigate the cost overruns.

NASA Site for On-line Learning and Resources (SOLAR), has some on line training as well. The Defense Acquisition Guidebook also has a section on Software Safety online training; MIL-STD-882D, "DoD Standard Practice for System Safety".

While in the Software Safety area of space flight check out Software Safety and Rocket Science by Gerard J. Holzmann in ERCIM News. Issue #75 covered Safety-Critical Software.

In my last blog entry I mentioned Circuit Cellar Magazine. In the April 2011 issue George Novacek took on the DO-178B software assurance standard. George details the standard, as best as you can in the allowed couple of pages, then seemed to imply at the end, that doing all of this paper work doesn't make the system much safer. Over the years I've seen both sides. Not having good written requirements leads to nothing but never ending project changes (changes are normal, but if you don't know what your setting out to make, you never know when you are done), cost overruns, and missed deadlines. On the other side having so much paper work that you can never actually ship a product out the door puts any company selling Embedded Systems out of business.

Hacker's Delight at Bit Twiddling Hacks

Michael Barr's Firmware Update newsletter for August 13th [2010] is just out.


Mike made a comment about his favorites bit twiddling methods, taken from Bit Twiddling Hacks by Sean Eron Anderson.  Worthy of any programmers time to read.


I wanted to add that there is a book written about the subject as well, Hacker's Delight by Henry S. Warren Jr; Addison-Wesley, 2003. ISBN: ISBN-13: 978-0201914658  Along with the books adjunct site.




The book covers the fast way to get many of the common firmware problems solved.  It is one of the books within easy reach of my development system most of the time.


It would be interesting to see if using the modern 'Typeof' found in newer compilers would let us do any of these bit twiddles even better.


Now for the down side.  If I was doing a Code Inspection and came across a magic number like 0x077CB531UL, with no explanation that this is a de Bruijn sequence, in the comments without lots of references, I would be appalled.


Bit Twiddling hacks are great in the few times that you need them, where you have to minimize branches, or maximize performance in a limited area, but always keep in mind the best programmers write simple code...

Does Time Keeping become a safety issue during Leap Seconds in a Leap Year?

At the end of 2008 we had a unusual event of a double compound time leap. 2008 was both a Leap Year, and ended with a Leap Second.

Wikipedia covers how to calculate Leap Years quite well, so I will not duplicate what should be very well known rules of how to calculate leap years here. Sadly it seem programmers don't know these rules. After all as far back as 1886 Christian Zeller came up with Zeller's Congruence to calculate the day of the week, and he got it right without even knowing what a computer was.

The event that most are talking about today, are the locking up of Microsoft's Zune 30 gigabyte devices.

While most people are bashing Microsoft for the problem, the problem really lies in the i.MX31 Board Support Package from Freescale. After registering you can download the i.MX31: Multimedia Applications Processor Board Support Package (FSL-WCE500-14-BSP), with full source code.

The now infamous file rtc.c, as reported on may other Zune related web sites, may be found in WINCE500\PLATFORM\COMMON\SRC\ARM\FREESCALE\PMIC\MC13783\RTC. The lockup bug comes down to the error that there will never be 367 days in *any* year in the function ConvertDays:

 while (days > 365)

  {

    if (IsLeapYear(year))

   {

    if (days > 366)

     {

      days -= 366;

      year += 1;

     }

    }

   else

   {

     days -= 365;

     year += 1;

    }

  }

The line should have read "366 == days" or my preference "days >= 366". A simple Code Inspection should have caught a simple minded bug like this during a design review. We can only assume based on this code, and other questionable constructions in the same file (I did not look at other files), that no such inspections or reviews were done. It is also clear that they didn't even running something as inexpensive as Lint on their code. Doing so would have weeded out several of the non-executable paths that are present.

There have been Leap Second related crashes of various devices, beyond Zune related to Leap Seconds, such as some Linux Kernel Versions. So what I want to concentrate on is the Leap Second. A Leap Second may be inserted or removed to get the common UTC time standard in sync with the Earth's Rotation.

What is more insidious than rtc code above is that any product based on the MC13783 Power Management and Audio Circuit chip, as used in the crashing Zune's, is doomed from the start, because at the hardware level it is impossible to support Leap Seconds correctly. To be fair to Freescale most second counting clock chips have the same problem.

"4.1.2.2.1 Time and Day Counters

The real time clock runs from the 32 kHz clock. This clock is divided down to a 1 Hz time tick which drives a 17 bit time of day (TOD) counter. The TOD counter counts the seconds during a 24 hour period from 0 to 86,399 and will then roll over to 0. When the roll over occurs, it increments the 15-bit DAY counter. The DAY counter can count up to 32767 days..."

According to the National Institute of Standard and Technology on Radio Controled Clocks (page 27) a properly functioning clock would tick from 23:59:59 to 23:59:60, then to 00:00:00 during a Leap Second event. So a single day could have 86,400 seconds, counting zero.

A clock that that is not capable of display 23:59:60 would have two consecutive displays of 23:59:59.

Leap Seconds do not always add a second, they can also subtract a second, so a 'day' could correctly only have 86,398 seconds.

From a software perspective something like libtai that supports two time scales: (1) TAI64, covering a few hundred billion years with 1-second precision; (2) TAI64NA, covering the same period with 1-attosecond precision. Both scales are defined in terms of TAI, the current international real time standard, is worth considering. As long as the Leap Second tables are properly kept up to date, which presents problems of its own.

If you really want to dig into issues of Leap Seconds then check out the LEAPSECS -- Leap Second Discussion List. Also if you are in any way interested in the preciseness of time keeping then check out the Time Nuts Discussion List at the LeapSeconds site.

I am not aware of any loss of life, or loss of major income, due to any of the Leap Second problems that occurred this time. Will we be able to say the same for the next Leap Second that occurs?