Slashdot Mirror

"The findings: An Amazon Kindle emitted less than 30 microvolts per meter when in use. That is only 0.00003 of a volt. A Boeing 747 must withstand 200 volts per square meter. "

EMF fields are measured in V/m. He's got one side right, but the "200 volts per square meter," is nonsense. Additionally, the actual 200 V/m measure is from RTCA DO-160 Section 20, and refers to external fields, which are in large part shielded by an aircraft's metal skin. And, the criteria for success is not a lack of interference, but whether the aircraft will continue to operate after experiencing a brief event of that magnitude. Indeed, there is every expectation that normal communications will be lost when subject to that level of signal.

A better, and more honest, comparison for that 30 uV/m the Kindle put out would be to consider that a decent FM radio can get stereo reception with a signal of 2 uV/M. That's reasonable, as FM frequencies (88-108 MHz) have similar characteristics compared to those used for aircraft communications (108-137 MHz), which are immediately adjacent. RTCA DO-196 assumes a radio sensitivity of 20 uV. So, a Kindle can compete in signal strength with those normally received by an aircraft communications receiver.

This issue is not what level of emissions from a device will cause damage, but whether they can interfere with aircraft operations. Just as the author conflates uV/m with uV/m^2, he's also ignorant of what's really important.

Having said that, it's unlikely that a Kindle (the example given) emits enough in the aircraft radio band to cause problems. I'd be more concerned with a bunch of cell phones, each with a GPS receiver built in, interfering with the aircraft's GPS based systems. GPS operates at even lower levels. But, I'd trust someone who actually understands the issues to make a real study to determine the risks, rather than take the word of an obviously biased ("writing skeptically for years") writer who gets even the basics wrong, after years of writing about the subject (or is being deliberately disingenuous).

SC-203
Unmanned Aircraft Systems

Many federal agencies and commercial operators are currently operating or seeking authority to operate Unmanned Aircraft Systems (UAS) in the National Airspace System (NAS). SC-203 products will help assure the safe, efficient and compatible operation of UAS with other vehicles operating within the NAS. SC-203 recommendations will be based on the premise that UAS and their operations will not have a negative impact on existing NAS users.

http://www.rtca.org/comm/Committee.cfm?id=45

Dave

The two public reasons, interference with other systems, could easily be tested, but neither the FAA nor the FCC manage to do such testing.

/HJ

The two public reasons, interference with other systems, could easily be tested, but neither the FAA nor the FCC manage to do such testing.

/HJ

The Yamaha RMAX (mentioned in the article) is a nifty helicopter. It uses a water cooled engine, has composite body shell, airframe, and rotor blades, and a nice onboard computer called YACS. Recently, a nearby company in collaboration with the local university installed a third party autopilot system that interface with the YACS and a ground station controller. The RMAX had first autonomous flight at a remote Air National Guard range and was successful. The 150 meter range restriction placed on the helicopter has very little to do with its performance; the RMAX can easily fly much farther and higher. Some useful applications for an RMAX in the US would be for highway traffic monitoring in busy cities ($150,000 UAV vs. several million dollar Bell 206), search and rescue, surveillance, and low cost aerial photography.

Aircraft can avoid each other, contrary to what the article states. Other users have mentioned TCAS, which warns a pilot when he is too close to another aircraft. The system interfaces with the aircraft's transponder and flight control system to decide what course correction should be made. For two aircraft approaching each other, opposite instructions will be given to the pilots so they fly away from each other. In a UAV, a system like this can be easily modified to simply command the flight control system to change course. In coordination with sense-and-avoid systems (RADAR), terrain avoidance, and other aircraft transponders, a safe automatic flight control system can be made for UAVs.

The technology for UAVs is young, and the equipment being used in many UAVs is not up to par because the only regulation is "you can't fly UAVs." Commercial airliners have triple redundancy for flight critical systems. If you think you have a rat's nest of cabling in your server rooms, you've never seen the wiring in a jet. Even a business jet has a enormous quantity of wires running through it. The reason for so much redundancy is very simple: if aircraft systems fail, people die. Death is generally bad. Since there is nobody onboard UAVs, the same redundancy is rarely installed. I have not worked with a single UAV that has any sort of redundancy for flight critical systems. Now, I'm not saying all UAVs are this way; the GlobalHawk is most certainly well equipped with redundant systems. Because the manufacturing cost of UAVs is so much lower than manned aircraft, many are considered expendable. The maintenance costs of manned aircraft are very large, and for some aircraft, those costs can eclipse the acquisition price very quickly.

There are many people involved in working with industry and the government to get UAVs flying in the US. Standard and regulations need to be formed, and I know several folks involved with that. Take a look at RTCA Special Committe 203 (SC203 Unmanned Aircraft Systems). Also look at groups like the Kansas UAV Consortium. They are comprised of industry, academia, government, and military partners dedicated to promoting UAV operations in Kansas and the US.

The UAVs flying today are rather impressive. In October I was an exhibitor at the Unmanned Aerial Systems/Future Systems Symposium. There were demonstrations of the Aerovironment Raven and AAI Shadow 200 UAVs. Both the Raven and Shadow demonstrated very good flying qualities. The Shadow even performed a flawless landing on a dirt runway.

Safety issues will be solved. If you're worried about the safety about civil UAVs when they get here, you aren't

I'd suggest reading Software Safety by the Numbers at http://www.embedded.com/showArticle.jhtml?articleI D=19201765 on IEC 61508 for safety critical industrial software or getting a copy of RTCA DO-178B from http://www.rtca.org/ for avionics.

I don't want my computer to clique me into a particular "community".

I want it to be a toolbox that allows me to be a part of many communities I choose to join.

And if you don't like the software available, it is, you know, possible to write your own, to your - or the world's[1][2][3][4][5][6] - standards of function, style, consistency, robustness, and hipness.

So is it Windows's fault that it's too broad and not restrictive enough on new tools, or is it Mac's fault that it's provincial and overweaning?

A good place to look is "Software Requirements--Revision" by Alan Davis (1993). I don't agree with everything Davis has to say, but the book is full of good ideas and potential "gotchas" to watch out for. Another good reference is DO-178B, the guidelines used for the development and testing of safety-critical software in commercial aerospace applications. It is available from the RTCA for about $50.

If you're doing an OO project, then you might want to look at Booch's book: "Object Oriented Analysis and Design" and the UML 2.0 specification .

But, most importantly, you MUST have some kind of design documentation (requirements, at a minimum) and that documentation needs to be flexible enough to accomodate changes without causing everything else to grind to a halt while the revisions happen. Expecting to get good software with inadequate formal documentation, minimal planning and insufficient requirements is why 70% of all commercial software projects end in failure (documented and published statistic).

Anyone who says you can do good software by shooting from the hip is nuts. And they don't work for me.

You can order a copy of the DO-178B guidelines from RTCA (the publisher), although the standards make about as much sense as the standards for NASA or the FDA.

Two reasons (there are more, but these are the best ones that come to mind immediately):

(1) The next time you park yourself on a commercial airliner you can be thankful that the software controlling the engines, the autopilot and the cabin pressure controls, to name just a few subsystems, was reviewed exhaustively at every step in the life cycle. They do this for a reason: It finds errors that testing alone cannot detect. [DO-178B, Section 6, available here]

(2) If fixing an error during implemention costs, say, 1 unit of resources (the baseline), then fixing that same error during requirements generation will only cost 0.2, and fixing it after deployment will cost upwards of 20 times the baseline. [from Software Requirements, by Alan M. Davis]

People who don't do reviews during the requirements, design and implementation phases are destined to spend their time poking their buggers and trying to explain to annoyed customers why the software doesn't work. Putting the effort up-front into good requirements design and code reviews makes the final testing and verification so much easier.

As for myself, I detest debugging at the tail-end of the life cycle; I'd much rather be moving on to the next fun project. Wouldn't you?