is all you'll have when it returns. Getting people out in deep space and back isn't a problem, its keeping them alive after they travel beyond the Earth's magnetic field. The rocket is technology that has been around for some time and simply a matter of building it in a particular configuration (simply as in getting the funding to do it right the first time).
Personally, I'd love to take a trip to Mars, but not if it means developing cancer on the way back, or even a few years afterwards.
When control system problems are viewed as either hardware or software in nature then the source of the problem can be very difficult to isolate. Instead, the systems a whole needs to be looked at objectively as to what could be the source of the problem.
So far all I've heard is probes into stuck gas pedals and software review. Of course, if the problem is not a stuck gas pedal then the assumption is the hardware is fine. If the software is tested thoroughly, then it too must be fine and the problem doesn't exist. Yet, something is happening.
Having been involved in the hardware and software investigation of very intermittent problems, it's not surprising to see these discussions. This happens when the vendor doesn't really want to find the problem, but rather put the blame elsewhere.
There are other sources of problems, and they can be difficult to replicate and even harder to fix. The two most common areas I've experienced have been timing and interference. Timing issues can be anything from handling of interrupts out of sync with clocks or other code. Interference can affect sensors or logic levels from external RF energy, electrostatic discharge, or noise from in-circuit inverters. Interference is the toughest because the source that happens in the field doesn't always exist in the lab.
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding that is either insufficient or not properly installed, thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy. Elimination of the source of the energy at the hardware is one method of solving the problem, but it doesn't hurt to have the proper software rules in place to insure that exception conditions are handled properly (for instance, you shouldn't need to press the brake and accelerator to force the vehicle to slow down. When the assumption is the accelerator is stuck and you only try to press the brake, nothing happens because the accelerator isn't actually stuck... duh).
Instead of testing such narrow parameters for the situation to appease Congress, Federal officials, and Toyota Management, a broader scope should be done. The quickest way would be by Toyota engineers who have knowledge and access tot he internals, but if they cannot be open minded about it then a third party with full access to the designs might be in order.
As an Amateur Radio operator, I have to do an analysis of my transmitting station to insure the field strength in my immediate area and my neighbors areas are in safe levels.
As any operator knows, beamed radio frequency energy has a specific width, side lobes, and spill-over. In other words even though 90% of the energy may be hitting its target, a considerable amount will be hitting the surrounding area. The energy doesn't just stay in the desired beam area, especially over that distance.
So while I'm concerning myself with documentation of 50W transmissions to insure safe exposure, this power transfer system will likely be exposing many people to much higher levels.
I suppose one advantage to residents of the area will be that they no longer need to heat their homes in the Winter. They'll just have that nice warm feeling all year long.
I see the long term results of this strategy similar to electricity and phones. Companies can not arbitrarily turn off your phone without a valid arguement that can withstand courts.
Some Internet connections may already be in this situation, although it has not been tested in court AFAIK. There are a number of people whose sole phone access is through their broadband Internet connection (such as Vonage or Time-Warner). These telephone providers already have the burden of providing 911 service, so why not lifeline service also?
Re:The Elements of Programming Style
on
Clean Code
·
· Score: 0
I agree, this book is small but sends the right message. Should be required reading for anyone involved in programming of any sort.
It starts off with a small Fortran program that is efficient but entirely cryptic. The cleaned up version makes it self explanatory and loses nothing in efficiency, especially with modern compilers.
I'll probably get this "Clean Code" book also, but I'll never part with my "The Elements Of Programming Style"
Back when structured programming methods were gaining popularity we began creating our own standards covering the design phase through coding (all in C but applicable to anything). Sandia National Laboratories published a set of papers describing how they do this in great detail. It is quite extensive and worth reading. Depending upon the size of your company and teams you may want to use all of it or scale it down.
I'd also recommend making "The Elements of Programming Style", by Kernighan and Pauger required reading by all involved.
In true Michael Crichton fashion, his book Prey delivers a good story with enough technical background thrown in to give the reader a bit of insight to the technology contained in the story.
The story is exactly the same sort of thing as these frisbee robots are attempting to become, just a different scale. Kewl and scary at the same time!
Slashdot Mirror
is all you'll have when it returns. Getting people out in deep space and back isn't a problem, its keeping them alive after they travel beyond the Earth's magnetic field. The rocket is technology that has been around for some time and simply a matter of building it in a particular configuration (simply as in getting the funding to do it right the first time). Personally, I'd love to take a trip to Mars, but not if it means developing cancer on the way back, or even a few years afterwards.
So far all I've heard is probes into stuck gas pedals and software review. Of course, if the problem is not a stuck gas pedal then the assumption is the hardware is fine. If the software is tested thoroughly, then it too must be fine and the problem doesn't exist. Yet, something is happening.
Having been involved in the hardware and software investigation of very intermittent problems, it's not surprising to see these discussions. This happens when the vendor doesn't really want to find the problem, but rather put the blame elsewhere.
There are other sources of problems, and they can be difficult to replicate and even harder to fix. The two most common areas I've experienced have been timing and interference. Timing issues can be anything from handling of interrupts out of sync with clocks or other code. Interference can affect sensors or logic levels from external RF energy, electrostatic discharge, or noise from in-circuit inverters. Interference is the toughest because the source that happens in the field doesn't always exist in the lab.
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding that is either insufficient or not properly installed, thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy. Elimination of the source of the energy at the hardware is one method of solving the problem, but it doesn't hurt to have the proper software rules in place to insure that exception conditions are handled properly (for instance, you shouldn't need to press the brake and accelerator to force the vehicle to slow down. When the assumption is the accelerator is stuck and you only try to press the brake, nothing happens because the accelerator isn't actually stuck... duh).
Instead of testing such narrow parameters for the situation to appease Congress, Federal officials, and Toyota Management, a broader scope should be done. The quickest way would be by Toyota engineers who have knowledge and access tot he internals, but if they cannot be open minded about it then a third party with full access to the designs might be in order.
As an Amateur Radio operator, I have to do an analysis of my transmitting station to insure the field strength in my immediate area and my neighbors areas are in safe levels. As any operator knows, beamed radio frequency energy has a specific width, side lobes, and spill-over. In other words even though 90% of the energy may be hitting its target, a considerable amount will be hitting the surrounding area. The energy doesn't just stay in the desired beam area, especially over that distance. So while I'm concerning myself with documentation of 50W transmissions to insure safe exposure, this power transfer system will likely be exposing many people to much higher levels. I suppose one advantage to residents of the area will be that they no longer need to heat their homes in the Winter. They'll just have that nice warm feeling all year long.
I see the long term results of this strategy similar to electricity and phones. Companies can not arbitrarily turn off your phone without a valid arguement that can withstand courts.
Some Internet connections may already be in this situation, although it has not been tested in court AFAIK. There are a number of people whose sole phone access is through their broadband Internet connection (such as Vonage or Time-Warner). These telephone providers already have the burden of providing 911 service, so why not lifeline service also?
I agree, this book is small but sends the right message. Should be required reading for anyone involved in programming of any sort. It starts off with a small Fortran program that is efficient but entirely cryptic. The cleaned up version makes it self explanatory and loses nothing in efficiency, especially with modern compilers. I'll probably get this "Clean Code" book also, but I'll never part with my "The Elements Of Programming Style"
Back when structured programming methods were gaining popularity
we began creating our own standards covering the design phase
through coding (all in C but applicable to anything). Sandia
National Laboratories published a set of papers describing how
they do this in great detail. It is quite extensive and worth
reading. Depending upon the size of your company and teams
you may want to use all of it or scale it down.
I'd also recommend making "The Elements of Programming Style",
by Kernighan and Pauger required reading by all involved.
The processes work.
In true Michael Crichton fashion, his book Prey delivers a good story with enough technical background thrown in to give the reader a bit of insight to the technology contained in the story.
The story is exactly the same sort of thing as these frisbee robots are attempting to become, just a different scale. Kewl and scary at the same time!