Category: Embedded Systems

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) Rollover/Back-Up Forum : One Thread

Category: Embedded Systems

-- (y2ktimebomb2000@yahoo.com), December 29, 1999

Answers

The following I saved from the TB2000 forum. I wish I'd have saved the date and official author, but here it is:
(originally posted by the admirable "justanotherengineer")

Clarification on Embedded Systems http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=00 1eWJ

I can't stand it. Been reading the posts from today and I just cannot believe the way things are going. Even worse, a lot of it is financial as if we are all believing that there will necessarily BE an economy next year.

Without posting my resume, I will state that I worked mainframes from various aspects including system operations, operations management, system engineering and maintainance, systems analysis and systems programming. As stated in the post, I worked in digital and analog for several years until the increasingly large scale of integration of chip functions in those areas decreased the need for engineers, while simultaneously increasing the need for software engineers, at which point, like so many engineers of my acquaintance, I 'slid' over to the software side, without ever intending to. Since that time, I have worked contract at various places, as I alluded to in the post. Various industries, various product types, both embedded and distributed networks.

The real problem that I see is the embedded chips. Now, before the flamers out there get their typing fingers all twisted up in an agony of anticipation, let me point out that a very small percentage of embedded systems use date functionality. HOWEVER, and it is a big one, a lot of those systems probably *have* date capability, and in my 15 years of embedded work I saw any number of systems which really had no need to be dependent on dates at all, in order to accomplish their primary function, but which wound up with all sorts of bells and whistles which did depend on the date functionality, simply because it was there and could be used.

A Primer on Embedded Systems

I don't know if anyone has ever set down exactly what embedded systems are or how they work, in general. I haven't seen such a post. So I am going to leap into the breech and provide one.

Embedded systems are those which have a controller chip of one sort or another on a circuit board, inside of device, which control one or more of the functions of the device. Simple enough. They are the chips which run hardware, as opposed to *pure* software, of the mainframe, general pc environment, or the distributed networks, which perform 'calculations', in all of their many and varied incarnations.

There are, to my knowledge, 4 types of embedded systems, classifying them by the nature of the controlling device. Two of these I have experience with. These 4 types are:

I will not address numbers 3 and 4 any further, as they are not something about which I know a great deal. My experience doing logic design as an EE many years ago might allow me to stumble through PLA's, but certainly not PLC's.

However, having done a number of projects in a variety of fields, for a wide array of employers, ranging from the federal government, the DOE, the DOD, medical equipment, telecom, HVAC, and wireless companies, I feel qualified to expound a little bit on the first two. (I know, I know, the only thing I bring to the table is a 'self-reported' knowledge of these things, and 'How come you won't post your real name, and ..... Did you ever hear of a 'Yellow Dog Clause' in contracts? Does the term 'Non-disclosure agreement' ring any bells? And I realize that all I have is 'experience'. Certainly doesn't make me the equal of some of the self-proclaimed 'debunkers'.)

The primary difference between microprocessors and microcontrollers is that the latter were *specificallly designed* to control equipment. The former get 'pressed into service' to control equipment. The former require other chips to actually cause changes of state on hardware, heavy duty relays, I/0 chips, etc. The latter have them built into the chip itself.

One of the distinguishing features, which is directly related to that primary difference, is that, since the microcontroller was specifically designed for the task, all necessary functionality tended to be built into the chip. The ideal goal here was a single chip circuit board. This was a rare bird in the real world, but it did occasionally come to pass. But it was the ideal.

What this means is that, while a microprocessor has its program stored in PROM (Programmable Read Only Memory) or EPROM (Erasable Programmable Read Only Memory) or EEPROM (Electrically Erasable PROM), the microcontroller chip has its program in the on-board ROM (Read Only Memory). Now note the main distinguishing feature here. One of these has multiple types of memory available, all of which have the word 'Programmable' in their names. The other does not have the word programmable in it. The implications here are important. In one case, the chip can be reprogrammed by burning a new PROM and removing the old one and inserting a new one, or by erasing the old one and reprogramming it. In the case of the EEPROM, the hardware may have the correct voltages and amperage to actually do the reprogramming on the board itself and nothing has to be removed! In the OTHER case, reprogramming of the chip involves removing the old one, throwing it away, and starting over. Read that sentence carefully, understanding that the shortest cycle time for this operation that I have ever seen was 18 (That is EIGHTEEN) WEEKS! And that was for a very small scale application. A more normal cycle time for this type of operation is about 12-18 MONTHS, depending on the complexity, size of staff, operating budget, and test equipment availability.

Now, as I understand it, a truly impressive number of organizations are planning on doing 'fix-on-failure'. If the above discussion doesn't make you just a little queasy about this, try thinking what New York City, or Washington, D.C., or any big city will look like after 18 WEEKS without electricity or water, let alone 18 MONTHS.

I can already hear Flint saying 'But what makes you think they haven't replaced those chips?'. Well, I don't know that they haven't. But I do know that there has been no *spike* in demand for embedded designers. I do know that distributed networking applications is paying better than embedded. I do know that 3 former clients have approached me about possibly working on remediation of code, but only in the last two months. And the pay rate was so low as to be ridiculous. Keep in mind, they wouldn't be selling anything new, just making what is already there work after the first of the year. So it is 'maintainance' work, which is the lowest paying. Of course, in one case, replacing the chips would be a neat trick, since the manufacturer left the chip business 6 or so years ago. Which means that the entire system would have to be redesigned, since the chips used had some truly impressive, and non-standard, functionality.

The fore-going discussion, while long, provides much of the background as to why I am literally *terrified* about the upcoming roll-over. These are the things that actually make physical equipment work. Some of it is vital (think power companies, gas companies, water companies, etc), some of it is dangerous (think helium liquefication plants, chemical companies, high speed, high torque fans for air volume adjustment in HVAC), and some of it is just plain necessary (think gas station pumps, medical devices, traffic lights, Command, control, communication and intelligence for the DOD). And I have no evidence that they are being corrected. I have no *evidence* to the contrary, in fairness to the pollies, however, the problem I have is that there are some awfully obvious cues that I should have seen, which would have strongly indicated that something was being done, and these are not in evidence. At the same time, there is some small amount of weaker evidence that nothing is being done. ... Me, I gotta go down to Sam's Club, they got a sale on rice and beans. ....follow-up:

Actually, some of the systems that I have worked on will crap out as soon as the first date that is more than 1999 appears. They have some date arithmetic that will shut down. And thanks to EPA and OSHA mandates, (some of which, admittedly, were justified, particularly safety related concerns), the operators aren't going to make them work even though they KNOW that the reported data is incorrect. The equipment is made to be failsafe and when a sensor reports the wrong thing, or appears to be beyond calibration date, or (fill in any reason why anything might care about a date), then the thing shuts down and will NOT restart until the error condition is corrected. Which, in this case, will be NEVER. Which means you have to replace the stinking chip with one which won't see that particular thing as an error, which translates, a chip with a new program. (See that part about 18 week to 18 month cycle times and picture the Big Apple patiently waiting while ConEd waits for a new chip...)

Others will probably work fine until the first time they are reset or rebooted. At which point one of my favorite little gotcha's will happen. Back then, it was commonplace to lard the initialization of the chip with a whole slew of 'sanity checks' to make sure that the chip hadn't gotten hit by a cosmic ray or something, altering the program. (A legitimate concern, as, for example, the damage that a high speed fan can cause on unregulated startup has to be SEEN to be believed.) And one of those 'sanity checks' involved the date. As in 'date verification', which typically involved making sure it thought it was in the right century, which, of course, meant checking for a 19 on the beginning of the year.....

The difficulty with embedded systems is that they are complex, require comparatively enormous lengths of time to fix, and require hardware. (If the power is out, exactly how does one go about making new chips? take a little tiny chisel, a block of silicon, and about 1000 years....) As for the other types of equipment, the 'true' computers, they too may have problems, which might be remediated after the fact, except that most organizations now run on the extreme ragged edge, (I had a project plan, which incidentally was APPROVED, which called out two key engineers at 36 hour DAYS for 2 months. The deadline was *truly* inflexible, involving as it did a vice presidents bonus check and stock option), and any significant amount of work, over and above what there is right now will probably result in what is known to the trade as the 'snowball effect'. A description would be to take a snowball to the top of a mountain with a very long, very marked downward sloped, snow covered meadow. Place it on the ground, start it rolling, run like heck down the mountain, and try to catch the result. (Hint, don't try this at home kiddies, you WILL get squashed.)

/ / /

Posted by "justanotherengineer" in late November? To TB2000



-- me (not@here.com), December 29, 1999.

I believe the above was trwo differnt posts from JAE that I saved as one, with the secoind starting with "A Primer on Embedded Systems". Valuable info.

-- me (not@here.com), December 29, 1999.

There is another thread called (something like) embedded chips - embedded systems" up towards the top. Someone named "Cherri" wrote that she knew all about embeddeds and they were No Problem. I want someone who knows about embeddeds to read both the above messages (Cherri's and this one) and post some commentary. I know zilch/zero/nada and can't learn because I'm a non-tech type of person. But embeddeds seem to be one of the most potentially scarey aspects of y2k. People who know - please post something!!! Thanks, Pramada

-- Pramada (pram108@yahoo.com), December 29, 1999.

Moderation questions? read the FAQ