Analog Circuit Design Three Volume Collection. 40% off until May 17th less after.

If you do Analog Circuit Design then the three volume set Analog Circuit Design from Linear Technology must be on your bookshelf.

This week Linear Tech released Volume-III of the series Analog Circuit Design, Volume 3 - Design Note Collection. Edited by Bob Dobkin and John Hamburger.

Analog Circuit Design, Volume 3, Design Note Collection is the first effort to bring Linear Technology's Design Notes into one volume. Design Notes were first published over 25 years ago, and after producing more than 500 notes, the genre is still going strong. The teaching designs in this Design Note Collection help bring new designers up to speed and give experienced designers a starting point for even more sophisticated designs. This book has two purposes: to speed designs by presenting finished examples, as well as providing a teaching resource for designers.

The Design Note Collection is a comprehensive volume of applied circuit design solutions, providing refined and practical design techniques. The book includes an extensive power management section, covering switching regulator design, linear regulator design, microprocessor power design, battery management, powering LED lighting, automotive and industrial power design. Other sections span a range of analog design topics, including data conversion, data acquisition, communications interface design, operational amplifier design techniques, filter design, wireless/RF communications and network design.

If purchased from Elsevier, enter discount code ANACIR at checkout for 30% off each of the three volumes and save 40% when you buy the three volumes together. Promotion applies to print and electronic.

Unitl May 17th 2015, Elsevier, has an other discount to save up to 40% when you buy Science and Technology eBooks.

Solving pressure and condensation build up in your Embedded System.

Have you ever had a problem with pressure build up or condensation in one of your embedded devices? Gore-Tex Vents are a good solution today, but I thought you might find The Rest Of The Story interesting. What follows is slightly edited version of a message exchange of mine from the gEDA-User mailing list.

> Dave McGuire wrote:
> > Bob Paddock wrote:
> > I'd put them in a sealed box, with a Gore-Tex Vent so that the
> > enclosure can 'breath' but not pass water.
>
> This is an interesting idea. Can Gore-Tex be found in small
> squares for this type of application, or would one be stuck
> destroying an expensive jacket to get some?

Salvation Army or Good Will would be a good place to look if you want to go the clothing route, but there is more to the story.

The whole story goes like this: Gore-Tex was invented ~1978, used in clothing as everyone knows, and didn't really find many other uses then. Jump forward to 1982. I was designing a hand held control to run some 50 Ton Coal Mining Equipment. The control was a sealed box with a membrane switch on the front. We very shortly ran into problems. Taking it down into the Mine would cause a pressure reduction that would suck the switches in, activating the switches. Having a stuck switch on a 50 Ton machine with sharp cutting bits is *bad*. Very **bad**. Also found that taking it up in a plane, as non-pressurized luggage, would deform the switch by causing it to balloon out to about four times what it should be. From flat to nice dome. You then had worthless junk, it did not recover.

I had recently read about the properties of Gore-Tex, tracked down one of the engineers in the factory and asked him if he thought it would make a good vent for such an application. He said he had no idea, but he would send me several different types of the stuff to try out. Which he did.

Putting cloth over a whole in mining equipment would last a few minutes, on on optimistic day. So a colleague of mine, Don F., came up with this labyrinth sandwich to put the Gore-Tex between.

Take two flat disks, we used thick fiberglass, each about 1/4" thick. Mill out a pocket in both disks, place them face to face, then drill a hole through both disks at one of the ends of the milled circle. Now rotate a single disk 180 degrees. Put the Gore-Tex between the disks and epoxy. If you try to stick your Sharp Pointy Coal Mining Implement into the hole you hit the fiberglass and not the Gore-Tex. The assembly was then held in the box by a screw in the four corners. Pressure problem was solved.

Went back to the fellow at Gore-Tex to get more material, which he supplied. Thought our idea was a good one and filed for the patent. So he got it and Don and I did not.

Today you can buy Gore-Tex pressure relief vent off-the-shelf. Most a screw in type plug, but they come in all kinds of sizes.

Is there a rule of thumb for estimating the cost of getting circuit boards assembled?

A reoccurring theme I see on message boards is why does it cost so much to have some electronic widgets manufactured. Here is some background for you that might help explain that.

Is there a rule of thumb for estimating the cost of getting circuit boards assembled?

In a past life I worked for a large Contract Manufacturer, Matric Limited . I don't mean this to a plug for them, but the view of the place is helpful for the discussion.

To a CM it is all about *Time*. When it comes to parts, the actually part cost is really insignificant as far as cost contribution to assembly cost goes. Most of the cost goes to the time it takes to setup and tear down.

For a broad brush overview of cost steps:

One shot fee for getting your project into the system. Someone has to enter your Bill of Materials (BOM), and schedule into the amorphous blob known as "The System". Any change that you do triggers a recalculation, that you either pay for or is amortized across your boards. Every future order you place will have a small "trigger fee" to pay for someone to enter your order.

Included in that is a fee for someone to do a time analysis of the number of operations that your project will require. A unit time value is assigned to each operation, and each operation has a cost, that is, as far as I know, calculated by Magick (All CM's use Magick for this step to my knowledge).

If you supply the parts there will be fees for entering a carrying fee per new part number into The System. They will also charge higher fees if you send them parts that require extra steps to handle such as reels of parts without leaders etc. Some cost analysis guru at GM, long ago, decided to simply have a number in The System carries a charge of $50 or so per year per part number. The accountants just love to beat up the engineering department for "we have to many parts in the warehouse". Company owner wants to keep inventory turnover high. Also cost for physically getting your parts into The System, such has putting them in the warehouse, typing in the data etc.

There will be a scrapping fee to get your stuff out of The System if you take your project someplace else.

Those Non-Recurring Engineering (NRE) fees you either pay up front, or are amortized across the number of boards. This is why the range is highly variable between different CMs. Some hide the fees, some don't.

Also, when you supply the parts the price of each part will be market up by a *minimum* of 33% (More Guru calculations). If you don't mark the price up by this amount, you lose money each time you touch the part. You are charged for the use of the warehouse space, like renting a storage unit.

Now lets say you let the CM supply the parts, in general this will get you a lower per part cost for the commodity parts. As they will be using 100,000 0.1 uF 0603 caps a day, the pick and place machine will have that loaded. So you don't have to pay for loading your reel of much smaller volume part. Also the CM will have negotiated a much better price than you got from DigiKey. The downside here is that you lose some measure of control, which can be a problem if you have to meet UL/MSHA/FDA etc. regulations.

There are extra charges for projects that involve FDA paperwork, such a per lot tracking etc. Other acronyms apply as well, UL, FCC etc.

There is a fee for having the solder paste stencil made.

Now that the NRE's are out of the way, lets build a thousand Widgets.

Someone answers the phone and enters an order into The System to build a thousand Widgets.

The System checks the warehouse to see what parts are in stock. Your order is then routed to Purchasing to get the parts that are out of stock, or routed to planning to get your order into the build Que.

When your build hits the top of the Que:

Someone pulls the parts from the warehouse, at the minimum your PCB; time.

Your bare boards are put in an oven and baked to drive out any moisture, you pay the handling and electricity; time.

Your parts are loaded on the Pick-and-Place Machine; time.

The board go from the oven to SMT Assembly; time.

Someone pulls your stencil out of the rack and puts it in the paste machine; time. Paste is applied to your board; time and paste costs.

Your board is put into the Pick-and-Place and your parts are mounted; paste, electricity and time.

Your board then goes through the IR reflow oven for soldering; electricity and time.

The boards are then cleaned; fluids and time.

Any of your parts left on the P-and-P are removed, and put back in the warehouse, when Widget #1000 comes out the end of the machine; time.

The stencil is cleaned. You pay for whatever the cleaning fluid is and time.

The stencil is put back in the rack; time.

If your boards are in a array, they are then cut apart. It is cheaper to build arrays, but it adds this cutting fee; time.

If there are parts that could not be mounted in the P-and-P Machine they are done by hand, or put through the wave solder machine, then cleaned a second time. There is a big hit in costs for anything done by hand such as connectors, transformers, cable assemblies etc. Time.

The boards then go to Quality Control for the level of inspection that you paid for. Simple visual to full functional test. Time.

Boards leave QC and go to shipping where they are put in Anti-Static bags and cardboard boxes and shipped off to you. Time. You pay the shipping one way or the other.

There could also be Added Value items such as your boards are put in an enclosure. You pay for someone to do it, right down to the number of seconds it takes to tighten down the screws.

By now you probably have gotten the idea that Time is important. When you were looking up stuff in the DigiKey catalog were you billing yourself the time it took to do it? Probably not...

The 500 piece cost for the electronic parts from Digikey is about $4.20

Did you include the Anti-Static Bag, the yellow Anti-Static Sticker that seals the bag, the solder (price of metals is going up every day), and any board cleaning fluid chemicals / deionized-water in that price of $4.20, and the time to do those items? I didn't think so...

A good CM knows the cost of every operation and will be around a long time. A new CM doesn't know his costs. Hence the wide variation in CM quotes.

Matric developed a reputation for being a high price CM, and customers would leave based on cost, rather than value. However many of them would return after a while saying "we got what we paid for", and never left again.

In the end my advice is to analyze the value of the services you are paying for, not the cost of the parts.

Tech Companies Say Better to Import More Workers Than Retrain Experienced Ones

"WASHINGTON, March 19,2014 /PRNewswire-USNewswire/ -- Addressing a media conference call today, Scott Corley, executive director of Compete America, asserted that the large high-tech companies he represents would rather bring in more H-1B temporary workers than retrain experienced American employees."

...

Corley replied: "If it could be done as easily, there would be less value in the worker. ... You're saying it's easy to be trained into these fields, but if that were true, there would be no value; they wouldn't be high-paying jobs. You would be able to find them anywhere."

"Mr. Corley made clear companies would rather use the H-1B visa to hire younger, cheaper temporary workers," IEEE-USA President Gary Blank said.

...

-- http://m.prnewswire.com/news-releases/tech-companies-say-better-to-import-more-workers-than-retrain-experienced-ones-says-ieee-usa-251079061.html.

See also You'd Rather Import Than Retrain. Why? by Carolyn Mathas.

People wonder why the younger generation has no interest in getting in to the STEM fields. They are not stupid, they read garbage like the above just like you and I can. Why pursue such an education when the jobs only go to the cheapest people?

NASA's first-ever Software Engineering Handbook (SWEHB) released to the public

After years in the making, NASA has now released to the public their first-ever Software Engineering Handbook (SWEHB); NASA-HDBK-2203 (2013-02-28).

YouTube video showing how a person can navigate through the NASA Software Engineering Handbook to find software engineering related information. This video is about ten minutes long and can be used as a good training or awareness tool.

Each section of the SWEHB provides six areas of information per entry: the requirement, its rationale, guidance for implementation, notes for small projects, associated resources, and related lessons learned.

The 135 software engineering requirements for NASA projects are listed in a small, blue booklet, seventy pages long, called NASA Procedural Requirement (NPR) 7150.2 AKA NASA Software Engineering Requirements; View all pages in PDF. The new handbook is "A sort of hitchhiker's guide to the NPR". The handbook does not impose additional requirements; it is meant to be an assist.

Haley Stephenson explains how the SWEHB was developed as a collaborative Wiki in The Hitchhiker's Guide to Software Engineering at NASA. Many mangers do not seem to appreciate the value of using something like Dokuwiki to collaborate and document the development of a project. Without such documentation, years later, we are left to wonder "why did we use the red widget, rather than the better blue widget?". Perhaps they are afraid of Federal Rule of Civil Procedure Rule 26; Duty to Disclose; General Provisions Governing Discovery? See also Michael Barr's Dead Code, the Law, and Unintended Consequences.

Always keep in mind that Software never works in isolation. Safe Software is useless if the system as a whole is not safe. To that end make sure that NASA Systems Engineering Handbook (in PDF here) has a place on your desk or bookcase.

Related Documents:

• Standard for Software Assurance with Requirements Compliance Matrix [MS_Word] and Requirements Compliance Matrix [MS_Excel].
• Software assurance standard; NASA-STD-8739.8 (2004-07-28)
• Software Safety Standard; NASA-STD-8719.13 (2013-05-07)
• Software Formal Inspections Standard; NASA-STD-8739.9 (2013-06-17)

They could not afford Linux?

I was recently walking down Beverley Boulevard in Beverley Hills, where I walked past a store that my bank account is unworthy of entering. In the store's window there was a very large multicolor LED sign. What the sign was selling was the Windows[TM] crash dialog, asking for a button to be pressed. I'm sure this is not what the store wanted to be selling. My first thought on seeing this was "This place can't afford a sign that uses Linux?".

It is unlikely that the buyers of that sign had any idea of what made it work, until it crashed. Makes me wonder if we should start labeling our products like "Linux Inside"? A quick web search even found a GNU/Linux distribution intended for digital signs.

While Linux has no fee that does not necessarily mean it has no costs with designing it into a product. A designer that has only ever used Windows may end up spending less money designing in Windows[TM] due to the learning curve that it takes to embedded Linux in a product.

Something that I find a bit annoying is that the majority of the world thinks the choice is either Linux or Windows[TM] when there are other options available. Commercially there is QNX, vxWorks. uCOS-II and uCOS-III from Micrium, and other commercial vendors. I'm partial to uCOS-II myself, as you find my name in the first edition of the book for helping getting it debugged and documented.

In the Free and open-source software (FOSS) area there is NetBSD that works, and can be made to work, on many kinds of odd hardware. I'd prefer it over Linux due to its non-viral license. There is also Minux-III, the original Minux being the direct parent of Linux. Inferno is also interesting if you need a large scale networked system for something like a medical office application.

What uncommon systems do you recommend? Do you even think such systems are always required for embedded devices? Sometimes a simple 'big loop' might be enough, or be preferable as it is easier to verify.

Bug of the Month Ends

For the last ten years Gimpel Software has posted a short stand alone program with an obscure C bug in it, with the challenge to the reader to figure out the bug.

Gimpel does this to show off their static analyzer Lint, the nitpickyest of all programs, something that I use almost daily. Lint exposes bugs by looking at a project as a whole, with multi-pass value tracking, rather than just as a file at a time as most humans would. Lint also can test for compliance with various guidelines such as MISRA or The Barr Group's Embedded C Coding Standard.

You can even input your own bugs to test short snippets of code that you might come across. For example the abysmal "if( A==B==C )" found in some of Freescale's USB stack code (I'll save the rant on poor manufacture example code for an other time).

I always looked forward to the challenge of the Bug of the Month, sadly it has be discontinued in favor of a new blog (May not be operational until late summer). I really don't like how everyone thinks replacing something useful with something akin to 'Social Media' is a good thing, how about you?

Colleagues over the years have complained that Lint puts out to many warnings. That is usually the case of Linting legacy code. Error messages may be turned off in layers. Get rid of the ones that will crash the system first, followed by the ones that might, until you get down to none or the ones you are willing to live with. Also with people trying to turn serious development in to some kind of game, see Development has become the game. Whats your Potty Mouth Score today?, make Lint a game. Can you write code that will give no Lint errors today?

Blink a LED? Then live your life in fear of lawyers and software patents.

Time permitting I participate in the Open Source board layout software project PCB. A recent exchange in the patch tracker brought to light just how scared developers have become of lawyers. Why must we live in fear of these leaches on society?

At issue is one of the developers put a lot of effort in to a enhancement that would 'blink' the difference between two revision of the board layout, to make the changes stand out. To which I raised the potential issue of a user having Photosensitive Epilepsy. This is where certain light patterns can induce seizures in people prone to this problem (it is also being looked at as a 'non-lethal' weapon by the military; watch the movie Looker someday). The end result is that Bert, the developer, decided 'blinking' was unsafe because of the potential for lawyers to appear. How many times have you blinked a LED in that widget you are developing? Now you too can live your life in fear of lawyers. I'll let Bert explain his case, taken from the patch tracker:

Hi Bob,

Thanks for the warning.

The default delay value is 50, which means 50 centi-seconds, which equals to toggling every 0.5 seconds, which gives 2 Hz.
On my laptop it takes even longer than 0.5 seconds for the default value to toggle (twice a second).

The above UK site mentions:
[quote]
  Most people with photosensitive epilepsy are sensitive to 16-25 Hz. Some people may be sensitive to rates as low as 3 Hz and as high as 60 Hz.
[quote]

Nevertheless the user can still inflict some damage upon him/herself by changing the delay parameter, or tuning/modifying the software, their computer, or whatever.

My gut feeling (legal adviser) says it's better to withdraw any patch for any blinking whatsoever, due to the way the US legal system regarding injuries and lawsuits functions.

Bear in mind that the upstream pcb repository resides on US soil.
3 Hz is just to close to 2 Hz for me to feel comfortable.

Put in other words: risk = probability * effect --> I take zero chance and rather have no effect.

This leads us to the issue of software patents and patent trolls. Lindsay Blakely, on the staff at Inc.com, recently wrote the piece How Much It Costs to Fight a Patent Troll, describing what happens to us 'little guys' that don't have teams of leaches, sorry, lawyers, on staff.

See also The Private and Social Costs of Patent Trolls by James E. Bessen, Jennifer Ford, and Michael J. Meurer of Boston University School of Law.

I've been making my case against software patents for years with the example of R++, a mathematical process (that is not patentable), that would allow us to have far safer systems. What is R++ ?:

R++ is ''rules in C++''. R++ is an extension to C++ that bridges the gap between object-oriented programming and data-driven (rule-based) programming. Programs written in R++ have all the facilities of C++ plus a new programming construct: a rule. A rule is like an ''IF-THEN'' statement, but it sits apart from the procedural code and is triggered automatically upon changes to the data that it monitors. In effect, rules monitor object memory and react when their ''IF'' clause becomes true.

What are rules useful for?

• Applications can use rules to help maintain model integrity by enforcing invariants and detecting constraint violations in the model.
• Applications that monitor a physical system (such as a telephone switching system) can use rules to detect and react to critical states.
• Applications that are primarily reactive (such as an elevator controller) can use rules to express state transitions.
• Applications that apply engineering guidelines (such as in equipment configuration) or business policies (such as in loan analysis) can use rules to apply the guidelines/policies when each situation arises.
• As a software engineering aid, rules can be used as a kind of non-procedural exception mechanism for detecting and handling illegal states.

The problem is that through mega mergers, sellouts, and buyouts, no one can actually figure out who owns what. Lucent has a patent on the technology in R++ but AT&T owns the production version of the software. Commercial use of R++ is a bit more tricky. Neither Bell Labs Research nor AT&T Labs Research are in the business of distributing research generated software for commercial use. I was able to get a principal at Lucent on board with open-sourcing R++. However any contact at all with AT&T got a me a referral to the legal department voice mail. Despite repeated attempts at email and phone messages, I've never been contacted by anyone from AT&T. Is it any wonder they are so hated by most (cell-)phone users?

There is a Federal Register notice, Request for Comments and Notice of Roundtable Events for Partnership for Enhancement of Quality of Software-Related Patents, that the US Patent Office would like to form a partnership with the software community to figure out how to 'enhance' the quality of software patents. To that end, they are looking for comments and there will be two roundtble events sponsored by the USPTO, one in Silicon Valley, Tuesday, February 12th, and one in New York, Wednesday, February 27th. If you plan on attending you must register by Feb 4th. The USPTO plans to make the roundtable events available via Web cast. Web cast information will be available on the USPTO's Internet Web site before the events. Grok Law has more on the issue, and a copy of the relevant Federal Register pages may be found at IP Watchdog.

Leave a comment if you think you can make it to one of these events, and give us a first hand report, please.

A Principles and Practices Exam Specification to Support Software Engineering Licensure in the United States of America

The first quarter 2013, Volume 15 Issue 1, issue of Software Quality Professional from the American Society for Quality has a couple of articles on the state mandated licensing of software engineers, that I have been chronicling.

A Principles and Practices Exam Specification to Support Software Engineering Licensure in the United States of America (PDF, 142 KB) by Phillip Laplante, Beth Kalinowski, and Mitchell Thornton, along with some Supplementary Material (PDF, 483 KB).
Software Quality Professional has published many open access articles over the years, alas these are not among them, you must be a ASQ member to read them, this only serves to reinforce my view that this whole licensing issue is all about making money for those that sell training material.

Summary: In April 2013 several states in the United States will require licensure for certain individuals who are involved in the creation of software that can affect the health, safety, and welfare of the public. It is expected that eventually, all states and jurisdictions in the United States will require such licensure. Each state has different licensure criteria, but all include certain educational and experiential requirements, passing two tests, with one being a common test of engineering fundamentals, and the other a test of minimal competency in relevant areas of software engineering knowledge and practice. While the common test of engineering fundamentals exists, the software engineering examination does not. In order to develop this examination, the authors conducted a study using a multimethod approach in identifying the professional activities and knowledge/skills that are important to the competent performance of software engineers who serve the public. In this article the authors describe the study, the results, and the test specification that was derived. Demographic information for the survey respondents is also presented.

I'll summarize some of the highlights. The article opens by telling us that many engineers are exempted from licensure such as industrial or government entities. This reinforces what I said in my first article, this is about killing off the independent contractors and those with no formal degrees (Maryland does have a non-degree path to licensing, and other states will recognize Maryland's license). Also the information that I have gathered and posted about what each state is doing is up to date, where the cited material in the article is from 2010.
Most of the article is about how the statistics and sampling methods used to come up with the areas for the test, based on the format of The Standards for Educational and Psychological Testing, coming up with these main categories:

1. Requirements
2. Design
3. Construction
4. Testing
5. Maintenance
6. Configuration management
7. Engineering processes
8. Quality assurance
9. Safety, security, and privacy

Those categories were deemed the most important of those surveyed from IEEE-CS and IEEE USA, of which only 323 people participated. Apparently few to none of those returning the survey are doing firmware nor Embedded Systems. We need to have more representation in those groups? Personally I aways find it troubling that groups that I have no representation in are creating rules that affect my life. On the other hand I personally have no desire to participate in nor support such groups.
Data analysis by respondent subgroups was in some cases based on job title. This is ironic considering the Texas Board of Professional Engineers, one of the main groups behind licensing, states:

"The best way to avoid problems is to practice title abstinence." - What Do You Mean I Can't Call Myself a Software Engineer? by John R. Speed.

The supplemental material goes into detail about the demographics of the survey respondents.
Then we have this final nugget, saying that whole process may be improperly biased:

Finally, there is controversy as to the need for professional licensure and it is possible that those who disagreed with the need for licensure opted out of the survey upon receiving an invitation, thus biasing the results somehow.

Myself I would have abandoned this approach when I found that there was only a 7.36 percent participation. Guess if you have an agenda to push such things don't matter...
The Institute for Software Excellence 2013 (Indianapolis, May 6-8), sponsored by the ASQ Software Division, is planing to have a session on the professional licensing topic presented by Professor Laplante. The ISE website has not been updated as I write this with the exact details.

Yet More Government Responses on Software License Questions and Study Guide

This month I received responses from Maryland and Idaho to the questions I asked in August, and IEEE-USA has released the Study Guide for New Software Engineering Exam. See my previous blogs on the subject at Do you have your license to write firmware? and Government Responses on Software License Questions.

The Idaho Board of Professional Engineers and Professional Land Surveyors, sent me a formal written response via Snail Mail:

---

November 9th, 2012

Dear Mr. Paddock:

At its meeting on November 7 and 8, 2012 the Idaho Board of Licensure of Professional Engineers and Professional Land Surveyors voted not to utilized the NCEES Principles and Practice of Software Engineer examination at this time for licensing professional engineers in Idaho, but they may reconsider that decision in the future.

Please call if you have any questions.

Sincerely, David K. Bennion , P.E. Board Chair.

---

Nov. 13 2012

Dear Mr. Paddock:

In your e-mail of August 12, 2012 you asked a number of questions regarding the NCEES Software Engineering, Principles and Practice of Engineering Examination. Please excuse us for not responding sooner, but I needed to consult the Board in detail to be able to provide you answers to your questions.

You asked if the "Software Engineering" license will be required in Maryland. Maryland does not license engineers by discipline. So no a "Software Engineer License" is not required (because there is no Software Engineer license), However, the practice of any engineering discipline including software engineering in the State of Maryland, does require a Professional Engineer License, subject to the exception provided in statute.

You asked: "Should such a license be required by the state, will there be any distinction made between types of computer systems such as your desktop PC, your Smart Phone or an Embedded System (those that run your microwave and your car)?" The practice of engineering is defined in Maryland statue as including: consultation; design; evaluation; inspection of construction to ensure compliance with specifications and drawings; investigation; planning; and design coordination. The planning, design, evaluation of any kind of software that could affect the health, safety or welfare of the public would fall be included in this definition and be considered the practice of engineering in Maryland.

You asked: "What will the prerequisites for taking the test, should it become required? Software is significantly different than any of the current required licenses." The requirements for taking the exam are the same as any other Principles and Practice of Engineering Examination (see § 14-304 and § 14-305). You also stated that you are concerned that there "..will there be academic requirements that will exclude those that have been practicing in the industry for years, yet have do not have a degree from a state recognized institution" Current Maryland Statute provides a path for licensure without a degree (see § 14-304 and § 14-305).

You asked: "Does Maryland license by comity?" Yes, Maryland does license by comity.

You asked: "How often will this license have to be renewed and what is the expense?" A Professional Engineering License in Maryland is renewed once every two years. The cost to renew is currently $68.00.

Finally you asked: "As a holder of a CSQE, will there be any ramifications of using the word 'Engineer' on my business card or web site?" Only Licensed Professional Engineers may practice, attempt to practice or offer to practice engineering in the State of Maryland. This includes using the title "engineer" on business cards, web sites or any other forms of communications.

I hope this clarifies the issues you were concerned with regarding software engineering and the practice of engineering in Maryland.

Please feel free to contact me again if you need any additional clarification on these issues or additional information.

Pam Edwards Executive Director - DLLR's Division of Occupational and Professional Licensing [Maryland].

---

---

---

News Release: Study Guide for New Software Engineering Exam Now Available:

WASHINGTON (31 October 2012) - A study guide for those planning to take the new software engineering exam is now available from IEEE-USA. It includes 40 representative questions and solutions, a suggested reference list and test specifications.

The Principles and Practice of Engineering (PE) Software Engineering exam - PE Software exam -- will be offered by NCEES, The National Council of Examiners for Engineering and Surveying, for the first time in April 2013.

IEEE Fellow Dr. Phillip Laplante, a professor of software engineering at Penn State University's Malvern, Pa., campus and chair of the Software Engineering Licensure Examination Development Committee, said the study guide is an essential tool in preparing for the exam.

"All prospective exam takers would be well-served to review the book to help identify weaknesses in their knowledge prior to taking the exam," Laplante said.

The study guide is $39.99 for IEEE members and $49.99 for nonmembers. http://ieeeusa.org/communications/ebooks/info.asp?Keyword=career&Product=Software+PE+Exam+%96+Sample+Questions+and+Solutions#=

PE Software exam registration begins 17 December. Check http://ncees.org/exams to find out about your state's approval and registration process. See exam specifications at http://engineers.texas.gov/downloads/ncees_PESoftware_2013.pdf...

---

---

Just as I predicted the people that have been pushing this have a vested interest in selling training material. What prices should there be on safety?

"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.

Abstract:

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 ADExtract.py 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.

Abstract

"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.

How to keep a sharp focused mind, or How sugar makes you stupid

When designing Embedded Systems it is important to keep your mind sharp and focused.

A recently published study: 'Metabolic syndrome' in the brain: deficiency in omega-3 fatty acid exacerbates dysfunctions in insulin receptor signalling and cognition [PDF] shows that a high-fructose diet sabotages learning, memory.

Eureka Alert sums up the study in plan English as:

New study shows that a high-fructose diet makes you stupid, significantly inhibiting your brain's ability to learn and remember.

"Our findings illustrate that what you eat affects how you think," said Fernando Gomez-Pinilla, a professor of neurosurgery at the David Geffen School of Medicine at UCLA. "Eating a high-fructose diet over the long term alters your brain's ability to learn and remember information. But adding omega-3 fatty acids to your meals can help minimize the damage."

Do you think this perhaps this a conspiracy by 'Them' to keep us "Dumbed Down", as it is found in most off-the-shelf foods and drinks?

Personally I cut sugar out of my diet a long time ago, and became an avid reader of food ingredient labels, and feel a lot better for it.

Be warned, if you try to remove sugar from your died, you will soon discover just how addictive this substance in the typical diet really is, as I know first hand from when I stopped being a Doughnut Junkie. It was a miserable few weeks when I decided to go Cold Turkey on sugar. Once it is out of your system for a while, it does not take much for you to feel the effects, like all of your muscles starting to ache, of eating something that you did not expect to have sugar in it.

Always keep in mind you are what you absorb, no mater how good this poison to the mind tastes going down...

This weeks Dan Saks's Embedded C++ training

This week I spent three days with Dan Saks and twelve others in Cleveland taking in Dan's "Embedded Programming with C++" which presented techniques for developing robust and efficient embedded applications in C++. This was Dan's first ever public class on the subject.

A lot of time of the first day was spent going over the language of the C and C++ standards so that everyone in class was at the same level of understanding, with the end goal of being able to read the standards and be able to comprehend them. A lot of time was spent on the difference between declarations and definitions, scope, and linkage. Perhaps a bit to much time was spent in this area, as toward the end of the class on the last day things were starting to seem rushed.

On day two we covered how not to get the standard C++ library sucked into to our build, as this is usually the source of the perception of C++ code being bloated compared to plain C code. Also covered was the proper ways to use const and our friend and nemesis volatile; see "Nine ways to break your systems code using volatile". Spent the majority of the day building up an I/O class a step at a time. While Dan explained how and why each step was an improvement over the previous version. Some time was spent comparing the memory sizes of equivalent C and C++ programs. In the end the C++ program was only four bytes bigger than the C program. In some examples that where run on the ARM architecture the C++ versions were actually smaller than the C versions.

Day three Templates, and some discussion of Template Specialization, were covered. For example on the AVR XMega there is eight USARTs. Templates give a simple interface to cover the USARTS. Also covered was how to write read-only and write-only classes that would abort at compile time if they were used in the wrong direction, such as reading from a write-only register. One of the last thing covered was how to write a library that would cause the build to failed if anything used 'new' (perhaps it was hidden in a third party library), as MISRA frowns on dynamic memory usage.

Overall if you ever hear of Dan giving a class in your area, make the time to take it.

Will "Free Energy" be our future energy source? How to improve your Magnetic Monopole's Gate Drive.

I'm sure that you agree we need a new source of energy to power all of our embedded gizmo's. Nikola Tesla once said:

"Ere many generations pass, our machinery will be driven by a power obtainable at any point of the universe. This idea is not novel. Men have been led to it long ago by instinct or reason; it has been expressed in many ways, and in many places, in the history of old and new. We find it in the delightful myth of Antheus, who derives power from the earth; we find it among the subtle speculations of one of your splendid mathematicians and in many hints and statements of thinkers of the present time. Throughout space there is energy. Is this energy static or kinetic! If static our hopes are in vain; if kinetic - and this we know it is, for certain - then it is a mere question of time when men will succeed in attaching their machinery to the very wheel-work of nature." -- An address to the Institution of Electrical Engineers, London (February 1892)

Also there is the Hopi Prophecy: "After the third tribulation, a new source of energy will be discovered that taps the Earth Magnetic field." Is this the end of the Mayan Calender on or near December 21st, 2012? The end of the fourth Mayan age and the start of the fifth?

From the time of Tesla whose inventions are well known, if not always understood, to Nathan Stubblefield to more modern contemporaries like John Bidini, people have been looking for a source of power and communication that does not involve burning fossil fuels.



John Bedini - Peter Lindemann 2012 Science & Technology Conference, Friday June 29th (optional early registration), Saturday June 30th & Sunday July 1st, 2012. Seating is limited to 150 people!

If you spend any time surfing the web for new exotic sources of power soon or later you run in to the term "Free Energy". This does not mean that the energy is free, as in free beer, rather that the energy is 'unattached' or available from the ambient background.

Well intentioned people frequently publish what they believe to be a new Over-Unity source of energy. Over-Unity here meaning that the process is over 100% efficient. In almost every case it comes down to the person not understanding their equipment. Search YouTube and you will find examples of projects that are 105% or 110% efficient. Numbers like that are always measurement errors. Any true Over-Unity process will be thousands of times Over-Unity.

The measurement errors come from assuming all meters can measure all waveforms with equal accuracy, which is never the case. Every instrument that we, collectively, have designed has only measured those things that we know now to measure. Things that we do not know how to measure therefore can not possible exist, right? Most meters are designed to measure DC or 50/60 Hz. Measuring complex waveforms gives meaningless results. Measuring voltage on one meter and current on an other meter and multiplying the results to get an indication of power, Pi= E * I, is equally meaningless with complex waveforms. Proper measurements of "Free Energy" devices are done with True-RMS meters, or better yet Calorimeters (which could be a problem for endothermic Free Energy systems, that is they get colder while operating [These unbalanced systems are unhealthy to be around!]).

One of the most common Free Energy systems people start with are those that involve wire, magnets and "Back EMF". People get amazed that they get hundreds to thousands of volts out of a coil of wire when they only started with a 9V 'transistor-radio' battery. They fail to understand a fundamental formula of inductance: vl = L(di/dt). Where L=Inductance, di in current and dt rise/fall time. Play with dt the most and you see that you can easily get voltages of thousands of volts with very short times. This does not correspond to a gain in power. Watts are Watts. Various schemes are tried to recover this 'Back-EMF', which takes us to JPL. NASA's Jet Propulsion Laboratory document NPO-16268 Recovering Energy From Relays describes the following circuit:

When Q3 is on, transistors Q1 and Q2 are on, and there is current in relay coil L1. When Q3 is turned off, Q1 and Q2 are also turned off. The energy stored in L1, which acts as an isolated voltage source, is commutated through diodes D1 and D2 and returned to the source.

A common problem I see in 'Free Energy' circuits on YouTube and other sites is that someones circuit failed, and went up in smoke. People in the more esoteric realm's blame this on things like "Subtle Energy" overload and other such minutia. Here is the far more realistic explanation:

The very old GE SCR Manual Including Triacs and Other Thyristors goes into all of the gorey details of what is happening inside the part, when the "Magick smoke comes out", as it is unlikely you have the Manual at hand, in a nut shell:

What lets the Magick Smoke out of IGBTS, FETS and SCRs in most cases is turn them on to slowly, causing 'Spot Heating' of the die.

Think of a FET, or SCR, as hundreds of thousands, possibly millions, of very small resistors all in parallel, where each one can be turned on and off individually. The 'resistors' closest to the gate turn on first, and as the gate potential spreads across the die the rest turn on. The ones farthest from the gate turn on last.
With a slow gate turn on, a few of the small resistors nearest the gate are trying to carry all of the load, which they can't do, so they burn up, but the device does not fail quite yet. The next time the device is turned on, which may be only milliseconds away depending on your switching frequency, or days away depending on the application, some more of the resistors further in burn up. When the point is reached that there is simply not enough of the 'resistors' left to carry the load is when the Magick Smoke escapes, and the part dies a catastrophic death.

This is why the parts generally run "for a while" before failing. If it fails as soon as you fire it up the first time, you either had a catastrophic short in the load, possibly shorted caps that take a bit of time to 'wake up' before they hold a charge, generally fixed with 'Soft Start', or the gate drive really sucked big time.

There needs to a be a few *Amps* of current pumped in the gate of the larger parts, in very short periods of time, to get the gate potential to spread across the entire die as fast as possible.

You also want to get the thing turned off as fast as possible.

If you are not familiar with the concept of Magick Smoke, this is where all electronic parts run on Magick Smoke, because once the smoke comes out of the part, it no longer runs...

Have I only painted a bleak pictures of uninformed experimenters? Perhaps. Now what happens if the high speed, high voltage 'Back-EMF' spike causes the Aether to rebound around the operating devices? Can we get a couple of virtual particle Leptons to collide and give up a real electron, and not irradiate ourselves with Gama-Rays (nasty stuff), to our circuit?

For those choking on the word 'Aether', you need to get with the program. This is not the static Aether of long ago, rather a dynamic Aether (the kinetic energy of Tesla) seething with virtual energy, that has gone by over a hundred different names down through the millennium. If your still hung up on all that crap about Relativity then look up Experimental Detection of the Ether by E.W. Silvertooth, in Speculations in Science and Technology, Vol.10, No.1, 1987; page three. See also in that same issue beginning on page nine, On the Silvertooth Experiment summary by H. Aspden. Also see Standing Wave Sensor by E.W. Silvertooth and S.F. Jacobs, Applied Optics Vol. 22, #9/1 May 1983.

According to conventional physics there are four ways to generate electricity:

• Move a magnet in relation to a coil of wire.
• Move a coil of wire in relation to a magnet.
• Change the reluctance between the magnet and the wire. See John Ecklin. I plan on building mine out of Metglas (amorphous metal alloy for low Eddie Currents) with MWS square wire (denser packing of coils) for maximum efficiency.
• Oscillate the magnet above and below its Curie Temperature in relation to a coil of wire; Tesla Patents: US 396,121 Thermo Magnetic Motor and US 428,057 Pyromagneto Electric Generator, build one of your own.

So if our 'Free Energy' device is using magnets why not use some esoteric one sided ones? The closest thing to a magnetic monopole that you can build on your kitchen table is the Halboch Array. The long defunct site MatchRockets once showed how to build a one-sided refrigerator magnet, from standard cube magnets, as shows from the images I recovered:

 Lawrence Livermore National Laboratory Halboch Array based Inductrack:

Hopefully soon we will be able to buy powerful off the shelf Halboch Array based motors.
Patrick J. Kelly has put together a 2,400 page eBook. that he keeps updating, that covers the history and current state of 'Free Energy': A Practical Guide to Free-Energy Devices. While there are several historical and technical errors it is still worth a look, to see were energy has been and what is coming in the imagination of many. Before something can manifest in 'reality' it must be a thought of in the imagination...

Something you are sure to come across while looking into 'Free Energy' is Scalar Waves. The basic concept of a Scalar Wave are two signals 180 degrees out-of-phase that sum to zero to create a potential. The difference between a 'Scalar Wave' and the Aharonov-Bohm Effect is one of geometry, that I've still not wrapped my head around completely.

Significance of Electromagnetic Potentials in the Quantum Theory by Y. Aharonov and D. Bohm in The Physical Review, vol. 115, no. 3, Aug. 1959.

Abstract: In this paper, we discuss some interesting properties of the electromagnetic potentials in the quantum domain. We shall show that, contrary to the conclusions of classical mechanics, there exists effects of potentials on charged particles, even in the region where all the fields (and therefore the forces on the particles) vanish. We shall then discuss possible experiments to test these conclusions; and, finally, we shall suggest further possible developments in the interpretation of the potentials.

and Quantum Interference and the Aharonov-Bohm Effect Yoseph Imry and Richard A. Webb in Scientific American, vol. 260, no. 4, Apr. 1989.

Abstract: Can electrons be influenced by a nearby magnet so well shielded that its force field cannot be detected? The counter-intuitive answer is yes: an energy emanation from the magnet known as the potential does indeed affect the electrons' wave function. This quantum-mechanical effect is being brought to bear on the development of new microelectronic devices.

What are you going to power your next Embedded System with? Conventional stuff or stuff of your imagination that you will bring to reality?

Gravitational Reflections in Plain English and Cold Stone

The following introduction is from "Gravitational Reflections in Plain English and Cold Stones" by Pierre Charles of Sacramento, CA. It seems fitting to almost all of the information presented in these pages...

Introduction:

I hesitate to discuss the new physics with most of the population, not that I do not want people to know, but because of the built-in opposition from the population's academic training and the possible misuse of this recently rediscovered source of understanding and power. Following close behind is the possible impact on the economic and control systems over the masses.
We are all slaves to this closed system of things to a degree. For example, we now live in a world of great knowledge and power; unfortunately, it is misdirected, so to live in relative comfort we hold an 8 to 5 job, wear clothes, drive cars, eat food all brought to us by others, and live in a house built by others and usually owned by the bank. Net result: both partners must work away from the home to support it. Meanwhile, the government takes back [more than] 50% to support those who cannot or will not work, and, of course, maintain the existing framework. The children spend most of the day being trained by others to fit into the existing framework, etc., etc.

This bring us to the opposition from academic-trained people, most are copies of copies, 10th generation receivers of what is unquestioningly taught as the eternal truth. Most are so far removed from the original information and thoughts that they do not recognize it and they oppose with great tenacity anyone who dares to defy their implanted ideas. This information will also disturb the traditionally religious people; I don't need to expand on the dangers there...

The New Physics:

To Truly grasp the new physics we must keep two things present in our minds:

1) The New Physics is actually a retrieval of the old or ancient physics,

2) The ancient physics encompassed all things; therefore, you must look at all things, you must remove all academic barriers from your present, considerably large body of knowledge and merge this with the eastern and ancient thoughts. If you find yourself laughing or ridiculing, then you will not find the valuable thread of information that you need...
Little remains of the ancient physics but it can be found nevertheless - for it has been preserved, often by those who had little or no true knowledge of the symbols that they considered sacred..."

Is Object Oriented C 'old-school' or the best way to attack hardware?

This comment by Igor Soumenkov of Kaspersky Lab on the Security List struck me as odd in the discussion of the Duqu Worm:

"All the conclusions above indicate a rather professional team of developers, which appear to be reusing older code written by top "old school" developers. Such techniques are normally seen in professional software and almost never in today's malware. Once again, these indicate that Duqu, just like Stuxnet, is a "one of a kind" piece of malware which stands out like a gem from the large mass of "dumb" malicious program we normally see."

What Mr. Soumenkov is commenting on is the use of Object Oriented C (OOC) techniques in the Duqu Worm. The Duqu Worm looks for information that could be useful in attacking industrial control systems. The part I find odd is the comment makes me think the people working to decode Duqu have no experience in the Embedded System space, where OOC techniques are common (they did not recognize the technique, and to their credit asked the Internet Community for help in identifying the technique). To me it just makes sense that to attack hardware you'd have people with hardware experience writing the attack. Why does that make such code 'old-school'? Continuing Mr. Soumenkov comment:

Having spoken to some of the people who prefer such techniques, they gave two main reasons for it:

1. They don't trust C++ compilers; these are usually people who started programming in the old days, when assembler was the top choice. C was a direct evolutionary step over assembler and quickly became a standard. When C++ was published, many old school programmers referred to stay away from it because of distrust in memory allocation and other obscure language features which cause indirect execution of code (for instance, constructors).
2. Extreme portability. Once again, in the old days (10-12 years ago) C++ was not entirely standardized and it was possible to have C++ code that would compile with MSVC but would not compile with (say) Watcom C++. If you wanted to go for extreme portability and target every existing platform out there, you'd go with C.

Both reasons appear indicate the code was written by a team of experienced, "old-school" developers.

...The event-driven architecture was developed as a part of the Duqu Framework or its OO C extension...

There are these Object Oriented C frame works, among others I'm sure:

• http://daifukkat.su/wiki/index.php/SOO
• http://ooc-coding.sourceforge.net
• http://sooc.sourceforge.net

SOO being particularly similar to the OOC framework used in Duqu but created to late to be the one used in Duqu.

So is your Embedded System code 'old-school' because it is Event Driven Object Oriented C, or your code is that way because that makes for efficient embedded code that is easy to maintain and adapt quickly?

From Its Birthplace: A Symposium on the Future of Nuclear Power, March 27 and 28th and the coming Grid Collapse

As you are going to be in the Cleveland area this week for Dan Saks visit, you might want to hang around until next week for the Symposium on the Future of Nuclear Power, in Pittsburgh. This symposium is sponsored by the University of Pittsburgh Dick Thornburgh Forum for Law and Public Policy and the Swanson School of Engineering.

The main topics of the for symposium sessions are:

Tuesday, March 27, 2012

• Nuclear Power and Energy Alternatives - 2:00 p.m. - 4:45 p.m.
• America's Nuclear Future - 7:00 p.m. - 9:30 p.m.

Wednesday, March 28, 2012

• Three Mile Island. Chernobyl. Fukushima Daiichi - 9:00 a.m. - 12:00 p.m.
• Legal and Financial Aspects of Nuclear Power - 2:00 p.m. - 4:30 p.m.

Registration for the event is required and there is a $300 fee to attend.

You may be wondering what this has to do with Embedded Systems or Software Safety? Westing House Nuclear is one of the largest employers for Embedded System Designers in the Pittsburgh region. Also, all of our widgets currently require to electricity to run them. Our current path of relying on 'Green' energy, and the closing of Coal based power plants is only going to lead to a failing Electric Grid as early as this summer (2012); I'll have more to say about that in a future blog.

Just this week the Utilities and the Department of Homeland Security ran a Power Hungry: Prototyping Replacement EHV Transformers test, better summarized as the Transformer Replacement Test.

As I've reported previously something like an EMP event, or a Solar Storm could put the Grid out of commission for days to months. Some of the mega-transformers have a two year lead time, when they need to be replaced. 90% of consumed power passes through a high voltage transformer at some point. If these transformers fail, especially in large numbers, therein lies a very big problem.

Small, local, Thorium Pebble-Bed Reactor buried in backyards solves the whole Grid collapse issue (there is no grid, or at least a very small one)...

Government releases Phase-I Anti-Distraction Guidelines. What will Phase-II do to your Embedded Design?

Do Not Text & Drive Public Service Ad Campaign by, regional Emmy award wining, Punch Films:

Mom:

Teen:

Guy:

Clearly as the above videos show texting while driving kills. I was almost in a head on collision myself when a texting teen was drifting into my lane of traffic. I've covered distracted Drivers, Doctors and Pilots in the past.

This week I'm covering U.S. Transportation Secretary Ray LaHood announcement, on Thursday [February 16, 2012], that the U.S. Department of Transportation (DOT) and the National Highway Traffic Safety Administration (NHTSA) announced their Proposes 'Distraction' Guidelines for Automakers. The official, unoffical, PDF document: Anti-Distraction Guidelines (It is not official until it is published in the Federal Register).

The Phase-I guidelines give members of the public the opportunity to comment on the proposal for 60 days, from the date of publication in the Federal Register. Final guidelines will be issued after the agency reviews and analyzes and responds to public input. If you are concerned about how these rules will impact your Embedded Widget design, now is the time to speak up. You may submit comments by referencing docket number NHTSA-2010-0053 at the Federal eRulemaking Portal.

NHTSA will also hold public hearings on the proposed guidelines to solicit public comment. The hearings will take place in March and will be held in Los Angeles, Chicago, and Washington D.C.

The proposed Phase-I distraction guidelines include recommendations to:

• Reduce complexity and task length required by the device;
• Limit device operation to one hand only (leaving the other hand to remain on the steering wheel to control the vehicle);
• Limit individual off-road glances required for device operation to no more than two seconds in duration;
• Limit unnecessary visual information in the driver's field of view;
• Limit the amount of manual inputs required for device operation.

The proposed guidelines would also recommend the disabling of the following operations by in-vehicle electronic devices while driving, unless the devices are intended for use by passengers and cannot reasonably be accessed or seen by the driver, or unless the vehicle is stopped and the transmission shift lever is in park.

• Visual-manual text messaging;
• Visual-manual Internet browsing;
• Visual-manual social media browsing;
• Visual-manual navigation system destination entry by address;
• Visual-manual 10-digit phone dialing;
• Displaying to the driver more than 30 characters of text unrelated to the driving task.

NHTSA is also considering future, Phase-II proposed guidelines that might address devices or systems that are not built into the vehicle but are brought into the vehicle and used while driving, including aftermarket and portable personal electronic devices such as navigation systems, smart phones, electronic tablets and pads, and other mobile communications devices. A third set of proposed guidelines (Phase-III) may address voice-activated controls to further minimize distraction in factory-installed, aftermarket, and portable devices.

The problem with any 'Guideline' is that if you don't follow it, when the Lawyers show up, if they ask "Did you follow the industries best practice guidelines?" and you say 'No', you lose. So it saves 'Them' all of the hassle writing the laws. Clearly Phase-II will impact our Embedded System designs.

Is regulating behavior with technology really the slippery slope that we want to start down?

Even "Design Patterns" still have bugs. A common Queue bug.

Recently I picked up the book Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit by Bruce Powel Douglass. I thought I might pick up some new techniques by reading this book. Always looking for that non-existent magic bullet for creating bug free code all of the time. Alas I was disappointed at the very first Design Pattern, the Queue. The queue design pattern as implemented in the book has a significant bug. The second queue design pattern, will show the bug even faster.

The queue design pattern is the classic first-in/first-out single writer, single reader queue. This 'Design Pattern' has been around for decades. I first used it on a Motorola/Hitachi 6301 in assembly language. Today I use Dave Hylands 'cbuf.h' to implement my queues.

Typically such queses are used where the writer is inside an interrupt routine receiving data from an external process, via something like a UART, Ethernet etc. and the reader is outside of the interrupt. Such a queue allows for the data to be received when presented from an asynchronous source, so it is not lost, rather than processing the data in the interrupt, which would length its run time (always a bad thing). The reader of the queue processes the data when it has the time and resources to do so, outside of the interrupt.

So what is this nasty queue bug? It is the asynchronous usage of the 'size' counter both inside, and outside of the interrupt routine without any type of protection:

#define QUE_SIZE (512U)
uint16_t size_u16;
void que_write( uint8_t const data_u8 )
{
...
++size_u16;
...
}

uint8_t que_read( void )
{
...
--size_u16;
...
}

On parts where 'size' is incremented atomically, say as a 16 or 32 bit indivisible operation there is no problem at all. Our nasty race condition bug will show itself at apparently completely random times on 8-bit machines.

Jack Ganssle went into the gory details of this class of race condition in his article on Asynchronicity (Also take a look at Herb Sutter's multi-part article on Lock-Free Code: A False Sense of Security), so I'll just summarize the problem here. Which is, if the que_write() interrupt happens just as que_read() runs, while the queue size count is 0x00FF, the size will end up wrong. que_read() reads the value of 0x00FF which is interrupted by que_write() that increments the value to 0x0100. que_read() not knowing this happened decrements the 'size' count and saves it as 0x1FE or 0x00FE depending on the implementation. A byte has been lost, or 256 have been gained, in the 'size' count. Things could deteriorate farther when the head/tail full/empty flags no longer end up matching the 'size' count.

Also, properly sizing a queue can be tricky. If it is to small, the queue will overflow and data will be lost. To large and memory space is wasted.

In the case of 'cbuf.h' the size must always be a power of two. As I've covered before I like to use compile time assertions to keep from shooting myself in the foot. I use the following to make sure a non-power-of-two will fail to compile:

#define UART0_RX_BUFFER_SIZE (128U) /* Size of receive buffer [Defined in my project file] */

/* Make sure buffer is sized to be a power of two [In my actual code, in different file]: */
#define UART0_RX_BUFFER_MASK ( UART0_RX_BUFFER_SIZE - 1U )
#if ( UART0_RX_BUFFER_SIZE & UART0_RX_BUFFER_MASK )
#error RX buffer size is not a power of 2
#endif

Something else that really bugs me about the book is that I ordered it in eBook format rather paper format. Elsevier eBook format is some creation of theirs that can not be read outside of their special reader for Windows or the Mac. So if you want to read on Linux, xBSD or a tablet, your just out of luck. Also as an anti-piracy measure if you print out anything, it comes out fuzzy. To make matters even worse I found they charged my credit card $1.19 for a fright charge! A freight charge for an eBook?? You'll be far better off to buy the real paper book, take a band-saw to the binding and scan it yourself that use this eBook carp. Maybe you'll want to join the Elsevier Boycott as well...