And who do you think "specifies what the software must do," never mind writes the software, tests, debugs, then validates that the control system operates as intended? Or are you among those who really believe that EEs spend all day using a soldering iron?
I can safely say that in decades of EE work, the only time I use a soldering iron is for my home projects. Engineering, by definition, is about design. The construction part is often not done by the engineer at all.
Need I say anymore,
I'm told by relatives that this could be a picture of me as I did the exact same thing at around the same age only with a fork.
As the story has been told to me by countless relatives, I was thrown backwards across the room at around 100 MPH before anyone could even yell out "No don't do it".
I guess I just had to find out why that magic box in the wall made the vacumn cleaner roar so loudly.
Needless to say my hair is now currlier than it was before my stunt.
I think this is how I got into high power RF amplifier design, 120 volts just wasn't enough for me after this.
Back in the early days of advanced CMOS processes (74ACxxx) Fairchild hadn't quite worked out the details of parasitic SCR latchup. I had one circuit using a 74AC04 inverter that exploded on me one day. Seems a software engineer wearing a rayon shirt and no ESD strap accidently rubbed up against the card, inducing enough voltage into an input of that IC to cause it's parasitic SCR to turn on.
When I looked at the package, the top of the epoxy had been blown out, there were bond wires hanging in air, and no silicon anywhere. It had all vaporized. I called up Fairchild, and gave them the component to analyze. I put a socket in that spot and put another inverter in there. From time to time I had to continue to replace them as their subsuently also exploded.
I heard a different story; that Airbus is incredibly arrogant and believes they know how to fly the aircraft better than the pilots do. When the pitot tubes iced up, the computers thought they were going slower than they actually were. When the pilots reacted correctly, the autopilot kept kicking in, taking control of the aircraft from them because their reaction was not what should be done when the pitot reports speeds near stall condition. needless so say the computers, not the pilots, crashed the plane into the Atlantic.
What about the Air France plane that went down in the Atlantic? Airbus is incredibly arrogant in that they believe they know better how to fly the plane than the pilots do. With both pitot tubes became iced over, the computers believed the aircraft was flying so slow that it was in danger of stalling. the pilots know that wasn't the ase. But the computers kept taking control from the pilots, putting the plane into a dive to pick up air speed until it crashed into the Atlantic. Supposedly one of the last things the pilots said before they crashed was they couldn't control the aircraft.
Needless to say the board of inquiry had to blame someone besides Airbus. The pilots' good names were thus smeared.
Thank goodness we didn't use Airbus for the next generation of in-flight refueling tanker aircraft!
Actually, the civil engineers were responsible since they didn't verify that the structure was built as designed. Someone substituted a cheaper part for what should have been used, and the engineers didn't catch it.
Vital steps missing.
Wear approptiate PPE.
Use approved meter.
Test live voltage.
Lock out Tag out.
Test for no or minimal voltage.
Next, re-test meter on live power, to verify meter is functional.
Now safe to work.
This is per NFPA70E.
Used in USA, Canada has similar rules.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.