Sunday, October 28, 2012

Near Death at the Rhine Research Center

The Eve of All Saint's Day better known as Halloween is almost upon us this week. It is a sad commentary on society when we remember to celebrate the demonic and forget the pure. Why do I bring this up?

This week I found myself in Durham North Carolina, at the International Association for Near-Death Studies, Inc. They let me checkout their private library once they figured I was not a flake chasing ghosts. No one in these organizations have any interest and don't want to be bothered by Ghost Hunters I did not see my favorite book on the subject, for those that are technically inclined, is The Ghost of 29 Megacycles by, one of my favorite authors, the late John G. Fuller. What thirteen tones would you use?

While Near Death Experience are interesting I was really here to visit the Rhine Research Center, that shares office space with IANDS, to discuss their research into Human Biofields. In 1930, academic research into the field of parapsychology began at Duke University and in 1935 the Duke Parapsychology Labs were established. Joseph B. Rhine led this department and provided a professional study of parapsychology in a university environment.

One of the projects fitting to Halloween is trying to verify the research of Dr. Duncan MacDougall whom in 1907 tried to figure out how much a Human Soul weighed at the time of death, by measuring the weight of the body immediately before and after death. There is also a bit of newer research in the 1980's. As the research center does not want to kill anyone/anything they are trying to weigh people that clam to be able to leave their bodies, and see if it changes when they come back. Regardless of what you may think of the experiment, it still offers technical challenges that need solved. How would you design a precision weigh scale that needed to measure a change of +/- 5 ounces? Load Cells, LVDTs, or something fittingly strange? There are interesting challenges of layout and power supply design as well.

I spent a good two hours taking to the Executive Director, John Kurth about their current line of research into Biofeilds, the reason for my visit.

I was a bit disappointed, as all they are using is a Photo-Multiplier Tube in the Ultra-Violet range. They get people that claim to be able to do Energy Healing and such. They put them in a double dark room, establish a base line. An empty room has about four photons per minute. With anyone, you for example, will be in the ten to forty photons per minute. Of the 150+ people that they have tried the test on, they have found ten that give repeatable results every time. Some people just give "spikes" of photons with no pattern to them. People that ask for feedback learn to make more photons. The best person puts out 600,000+ photons per minute consistently. The highest peak they ever saw was 1.2M but it was not repeatable.

The reason for my disappointment was they knew nothing about such things as Mitogenic Radiation, and could not tell me if their PM was made of Quartz or Glass, which is important. Mitogenetic Radiation is the force or specific energy that is supposedly given off by cells undergoing division. It may in turn stimulate the process of mitosis in other cells, better known as Gurvich Radiation, named after Alexander Gurwitsch. See also Otto Rahn Invisible Radiations of Organisms. V.P. Kaznacheyev work is summarized in The Excalibur Briefing. Kaznacheyev work has been more recently carried on by Michaylova in Novosibirsk, that explains the Quartz/Glass issue..

At any rate it was an interesting few hours. They have the largest library of PSI related books I've ever heard of, and that makes a visit worthwhile if you are in the area.

Saturday, October 6, 2012

"What Good Are Strong Specifications?"

"I'll go up and find out what they need [this project to actually do], the rest of you stat coding it [right now]" is meant to be humorous, alas I've seen it the Real World far to often. What is our new widgets actually required to do (Validation: Have we built the correct device? Do we meet the customer's requirements)? Which brings us to the subject of this blog, writing software specifications (Verification: Have we built the device correctly? Did we find and remove all of the 'bugs'?) and User Documentation.

What Good Are Strong Specifications? [PDF] by Nadia Polikarpova, Carlo A. Furia, Yu Pei, Yi Wei and Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland.


Experience with lightweight formal methods suggests that programmers are willing to write specification if it brings tangible benefits to their usual development activities. This paper considers stronger specifications and studies whether they can be deployed as an incremental practice that brings additional benefits without being unacceptably expensive. We introduce a methodology that extends Design by Contract to write strong specifications of functional properties in the form of preconditions, postconditions, and invariants. The methodology aims at being palatable to developers who are not fluent in formal techniques but are comfortable with writing simple specifications. We evaluate the cost and the benefits of using strong specifications by applying the methodology to testing data structure implementations written in Eiffel and C#. In our extensive experiments, testing against strong specifications detects twice as many bugs as standard contracts, with a reasonable overhead in terms of annotation burden and runtime performance while testing. In the wide spectrum of formal techniques for software quality, testing against strong specifications lies in a "sweet spot" with a favorable benefit to effort ratio.

- {Trackback}

In a less formal, more practical implementation to the everyday Embedded System Developer, Doxygen is a popular method of generating documentation from source code. Doxygen can be extended with 'alias' to add features, and a thread over at Stack Overflow, Custom tags with Doxygen shows how to add 'Requirement' and 'Requirement Verification' aliases.

While Doxygen excels at Program Documentation, it is often pressed into service to generate User Documentation, which far to often a novel concept to software authors, that is not the domain Doxygen was intended for and often has to be beat into submission. On the other-hand AsciiDoc is written specifically to author User Documentation, and can be used to extract the User Documentation from the source code files. If you truly want to keep your project on track then write the User Documentation first before any line of code is ever written. Keeping the Source Code, Program Documentation and User Documentation as a single file gives them the best hope of actually being maintained.

Something I always find extremely frustrating is the disconnect between Academia Research into Software Safety, and the Real World of "we must ship 782 Widgets by Friday to meet payroll!". Take for example Net-Centric Software & Systems Consortium's Software Safety Tutorial, that is reproduced below, which seems more like an expedition for finding more funding from industry. How do you actually apply this kind of information in the Real World? The European Network of Excellence of Embedded Systems Design is a bit more in-line with the concept that a product must having shipping it as one of its primary requiremnts...

Alas the problem is not just one of academic discussion as Dave Woll explains the issues of our aging infrastructure impending failure in The coming wave of process safety system migration: Systems changes require rigorous hazards analysis.

If you do like Slid Shows check out CPLD Course Draft International Software Safety Conference 2011:

"A Methodological Framework for Software Safety in Safety Critical Computer Systems"

The Journal of Computer Science is frequently overlooked in the Embedded Space for the solutions to many problems, for example the September issue covered topics as diverse as, Speed Control of Switched Reluctance Motor Using New Hybrid Particle Swarm Optimization for the hardware types and among us, and Fuzzy Cost Enabled Cluster Based Multipath Routing Algorithm for Mobile Ad-Hoc Networks for those putting together the latest sensor net.

Of particularly interest to me is A Methodological Framework for Software Safety in Safety Critical Computer Systems [PDF] by P. V. Srinivas Acharyulu and P. Seetharamaiah. These authors have put together one of the best introductions to issues related to the safety of systems controlled by software, from defining the terms to building a model system out of a real model train set to demonstrate the techniques described.


"Software safety must deal with the principles of safety management, safety engineering and software engineering for developing safety-critical computer systems, with the target of making the system safe, risk-free and fail-safe in addition to provide a clarified differentaition for assessing and evaluating the risk, with the principles of software risk management. Problem statement: Prevailing software quality models, standards were not subsisting in adequately addressing the software safety issues for real-time safety-critical embedded systems. At present no standard framework does exist addressing the safety management and safety engineering priniciples for the development of software safety in safety-critical computer systems. Approach: In this study we propose a methodological framework involving safety management practices, safety engineering practices and software development life cycle phases for the development of software safety. In this framework we make use of the safety management practices such as planning, defining priniciples, fixing responsibilities, creteria and targets, risk assessment, design for safety, formulating safety requirements and integrating skills and techniques to address safety issues early with a vision for assurance and so on. In this framework we have also analysed integration of applicability of generic industrial heirarchy and software development heirarchy, with derived cyclical review involving safety professionals generating a nodal point for software safety. Results: This framework is applied to safety-critical software based laboratory prototype Railroad Crossing Control System (RCCS) with a limited complexity. The results have shown that all critical operations were safe and risk free. Conclusion: The development of software based on the proposed framework for RCCS have shown a clarified and improved safety-critical operations of the overall system peformance."

Journal of Computer Science
DOI: 10.3844/jcssp.2012.1564.1575
Volume 8, Issue 9
Pages 1564-1575

Do keep in mind it is an introduction, a real Rail Road Crossing Control System (RCCS) would be made from two or more systems running parallel, using different processors, different hardware developed by different teams in different languages such C and ADA. The real fun part is developing a system that must run for a few decades and not the eighteen month life span for many components today.

More Government Responses on Software License Questions

I have been covering how the Government is getting involved in writing firmware in a couple of past blogs. Two more States have responded to my questions.

The state of Idaho previously said they would send me a formal written letter with their response. I now have that in hand as you can see below. While the nostalgia of a formal letter is nice, was it really required when a email would have done?

Board of Professional Engineers and professional Land Surveyors

Dear Mr. Paddock

At its meeting on September 5 and 6, 2012 the Idaho Board of Licensre of Professional Engineers and Professional Land Surveyors reviewed the email inquiry about licensing of software engineers which you submitted to David Curtis dated August 5, 2012. You have raised some interesting question which the Board has voted to take under advisement and study. We will communicate with you further after we have had the opportunity to determine how we will handle the issues.

Please call if you have any questions

For the Board [Signed] David K. Bennion, P.E. Board Chair

DLC/DKB/dc:Paddock,Bob.2012-09 Meeting

From the state of Mississippi:

Mr. Paddock,

At this week's Board meeting, the members reviewed and discussed your email below.

Your questions about the exam should be referred to NCEES (

The requirements (education, examination and experience) are all on our website at; look at Initial PE licensure requirements. These requirements are set by both Mississippi statutes and by Board regulations.

If a person passes the NCEES Software PE exam in Mississippi, then the person would be a licensed Professional Engineer in this state. The license expires every Dec. 31; the current renewal rate is $35 and 15 hours of continuing education every year.

Regarding the use of the title "engineer", Mississippi statute 73-13-39 restricts this title to those who are licensed Professional Engineers. When it comes to the Board's attention that an unlicensed person is using this title in a public manner, such as to to solicit business, to claim credentials or to certify something, the Board is compelled by state law to direct the person to cease and desist.

I hope this information is helpful to you.

- Rosemary Brister