Drones and The Wright Stuff

Input Voltage

–Jeff Child, Editor-in-Chief

JeffHeadShot

Commercial and consumer drones are among the most dynamic areas of embedded system design today. The industry that Circuit Cellar covers—and is a part of—is a vital enabler of these markets. Drone designs continue to leverage advances in processor/chip technologies, sensor innovations and power solutions that make up the heart of a drone’s electronics.

More than most areas of embedded system design, drones must be looked at within the broader perspective of issues beyond technology—in particular the many safety and regulatory issues surrounding them. After all, drones have to operate within the same air space as manned aircraft. And unlike the automobile industry, for example, the drone industry is relatively new with a regulatory landscape that’s still evolving and with many safety issues still to be resolved.

Acting FAA Administrator Daniel K. Elwell offered some insights on these subjects in his keynote address at this year’s InterDrone show early last month. He drew parallels to the high-level of safety that’s been achieved in commercial aviation to what the goal should be for drone safety. “Aviation is the gold standard,” said Elwell, “The safest form of transportation in the world. That’s not a position we’re about to take a step back on. I’ve heard this argument a few times: Back in Orville and Wilbur Wright’s era, people were willing to risk their lives for the birth of a new form of transportation. Now that we’re on the cusp of aviation’s next great era (drones), shouldn’t we be willing to accept some of the same risks in the name of progress? Folks, there’s a really simple answer to that question: No.”

“Manned aviation already learned those lessons. We paid that price. We’re not going to do it again. And the public wouldn’t let us, anyway.” Elwell made the point that with drones, you’re not starting from scratch like the Wright brothers. “The FAA has spent six decades working with airlines, manufacturers and countless others to get where we are now. And we’re ready to use everything we’ve learned so that the drone industry can reach its full potential as quickly as possible.”

Elwell went on to list some of the progress along these lines in the FAA and Department of Transportation. “We’re building flexible, responsive regulatory processes that can keep up with all your creativity while ensuring safety isn’t compromised,” he said, “We’ve automated how drone operators get permission to fly in controlled airspace. We’re laying the groundwork for a comprehensive Unmanned Traffic Management System. We’ve authorized low-risk small drone flights, and created a performance-based waiver and exemption process to allow more advanced operations.”

Another key effort is the Unmanned Aircraft Systems (UAS) Integration Pilot Program launched last October by US Secretary of Transportation Elaine Chao. The initiative partners the FAA with local, state and tribal governments, which then partner with private sector participants to safely explore the further integration of drone operations. In May of this year, the USDOT selected 10 state, local and tribal governments as participants in the UAS Integration Pilot Program. Data gathered from these pilot projects will form the basis of a new regulatory framework to safely integrate drones into the national airspace.

According to the USDOT, the 10 final selectees will work with the FAA to refine their operational concepts. Over the next two and a half years, the selectees will collect drone data involving night operations, flights over people and beyond the pilot’s line of sight, package delivery, detect-and-avoid technologies and the reliability and security of data links between pilot and aircraft. The data collected from these operations will help the USDOT and FAA craft new enabling rules. These will include rules for complex low-altitude operations and improving communications and addressing security and privacy risks.

In Elwell’s keynote he cited a fun story about the pilot program’s first test that happened just recently in Blacksburg, Virginia. A Project Wing drone delivered a popsicle to a two-year-old boy, just six minutes after the order was placed. “It was historic—the first beyond visual line-of-sight residential drone delivery in the United States,” said Elwell, “It was the ‘Mr. Watson, I want to see you’ for the 21st century. But to little Jack, it was just cool. In his words: ‘Airplane brought me a Popsicle!’ These are important steps forward—steps that bring drones closer to just being a routine operator in our airspace.”

This appears in the October 339 issue of Circuit Cellar magazine

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:

MCU/MPUs Target Next-Gen Electric and Autonomous Vehicles

NXP Semiconductors  has announced a new family of high-performance safe microprocessors to control vehicle dynamics in next-generation electric and autonomous vehicles. The new NXP S32S microprocessors will manage the systems that accelerate, brake and steer vehicles safely, whether under the direct control of a driver or an autonomous vehicle’s control.

NXP is addressing the needs of carmakers developing future autonomous and hybrid electric vehicles with newly available 800 MHz MCU/MPUs. The first of the new S32 product lines, the S32S microprocessor offers the highest performance ASIL D capability available today, according to NXP.
The NXP S32S processors use an array of the new Arm Cortex-R52 cores, which integrate the highest level of safety features of any Arm processor. The array offers four fully independent ASIL D capable processing paths to support parallel safe computing. In addition, the S32S architecture supports a new “fail availability” capability allowing the device to continue to operate after detecting and isolating a failure—a critical capability for future autonomous applications.

NXP has partnered with OpenSynergy to develop a fully featured, real-time hypervisor supporting the NXP S32S products. OpenSynergy’s COQOS Micro SDK is one of the first hypervisor platforms that takes advantage of the Arm Cortex-R52’s special hardware features. It enables the integration of multiple real-time operating systems onto microcontrollers requiring high levels of safety (up to ISO26262 ASIL D). Multiple vendor independent OS/stacks can also run on a single microcontroller. COQOS Micro SDK provides secure, safe and fast context switching ahead of today’s software-only solutions in traditional microcontrollers.

NXP Seimconductors | www.nxp.com

DC-DC Converter Family Targets Modern Railway Systems

Vicor has released its next generation of DCMs with a family of wide input range (43 V to 154 V input) 3623 (36 mm x 23mm) ChiPs with power levels up to 240 W and 93% efficiency, targeted at new rail transportation and infrastructure applications. Modern rail infrastructure requires a wide range of DC-DC converters to power a variety of new services for both freight and commuter markets.

Commuter rail systems require mobile office communication capabilities with the infotainment capabilities of home. Freight rail systems require monitoring and control capabilities to assure the safe and timely delivery of all goods onboard. While both commuter and freight systems demand reliable and high-performance power systems for the necessary safety and security measures (onboard and at station.)
The DCM is an isolated, regulated DC-DC converter module that can operate from an unregulated, wide range input to generate an isolated DC output. These new ChiP DCMs simplify power system designs by supporting multiple input voltage ranges in a single ChiP. With efficiencies up to 93% in a ChiP package less than 1.5 in2, these DCMs offer engineers leading density and efficiency.

Vicor | www.vicorpower.com

System Safety Assessment

System safety assessment provides a standard, generic method to identify, classify, and mitigate hazards. It is an extension of failure mode effects and criticality analysis and fault-tree analysis that is necessary for embedded controller specification.

System safety assessment was originally called ”system hazard analysis.” The name change was probably due to the system safety assessment’s positive-sounding connotation.

George Novacek (gnovacek@nexicom.net) is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

Columnist George Novacek ([email protected]), who wrote this article published in Circuit Cellar’s January 2014 issue, is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

I participated in design reviews where failure effect classification (e.g., hazardous, catastrophic, etc.) had to be expunged from our engineering presentations and replaced with something more positive (e.g., “issues“ instead of “problems”), lest we wanted to risk the wrath of buyers and program managers.

System safety assessment is in many ways similar to a failure mode effects and criticality analysis (FMECA) and fault-tree analysis (FTA), which I described in “Failure Mode and Criticality Analysis” (Circuit Cellar 270, 2013). However, with safety assessment, all possible system faults—including human error, electrical and mechanical subsystems’ faults, materials, and even manuals—should be analyzed. The impact of their faults and errors on the system safety must also be considered. The system hazard analysis then becomes a basis for subsystems’ specifications.

Fault Identification

Performing FMECA and FTA on your subsystem ensures all its potential faults become detected and identified. The faults’ signatures can be stored in a nonvolatile memory or communicated to a display console, but you cannot choose how the controller should respond to any one of those faults. You need the system hazard analysis to tell you what corrective action to take. The subsystem may have to revert to manual control, switch to another control channel, or enter a degraded performance mode. If you are not the system designer, you have little or no visibility of the faults’ potential impact on the system safety.
For example, an automobile consists of many subsystems (e.g., propulsion, steering, braking, entertainment, etc.). The propulsion subsystem comprises engine, transmission, fuel delivery, and possibly other subsystems. A part of the engine subsystem may include a full-authority digital engine controller (FADEC).

Do you have an electrical engineering tip you’d like to share? Send it to us here and we may publish it as part of our ongoing EE Tips series.

Engine controllers were originally mainly mechanical devices, but with the arrival of the microprocessor, they have become highly sophisticated electronic controllers. Currently, most engines—including aircraft, marine, automotive, or utility (e.g., portable electrical generator turbines)—are controlled by some sort of a FADEC to achieve best performance and safety. A FADEC monitors the engine performance and controls the fuel flow via servomotor valves or stepper motors in response to the commanded thrust plus numerous operating conditions (e.g., atmospheric and internal pressures, external and internal engine temperatures in several locations, speed, load, etc.).

The safety assessment mostly depends on where and how essentially identical systems are being used. A car’s engine failure, for example, may be nothing more than a nuisance with little safety impact, while an aircraft engine failure could be catastrophic. Conversely, an aircraft nosewheel steer-by-wire can be automatically disconnected upon a fault. And, with a little increase of the pilots’ workload, it may be substituted by differential braking or thrust to control the plane on the ground. A similar failure of an automotive steer-by-wire system could be catastrophic for a car barreling down the freeway at 70 mph.

Analysis

System safety analysis comprises the following steps: identify and classify potential hazards and associated avoidance requirements, translate safety requirements into engineering requirements, design assessment and trade-off support to the ongoing design, assess the design’s relative compliance to requirements and document findings, direct and monitor specialized safety testing, and monitor and review test and field issues for safety trends.

The first step in hazard analysis is to identify and classify all the potential system failures. FMECA and FTA provide the necessary data. Table 1 shows an example and explains how the failure class is determined.

TABLE 1
This table shows the identification and severity classification of all potential system-level failures.
Eliminated Negligible Marginal Critical Catastrophic
No safety impact. Does not significantly reduce system safety. Required actions are within the operator’s capabilities. Reduces the capability of the system or operators to cope with adverse operating conditions. Can cause major illness, injury, or property damage. Significantly reduces the capability of the system or the operator’s ability to cope with adverse conditions to the extent of causing serious or fatal injury to several people. Total loss of system control resulting in equipment loss and/or multiple fatalities.

The next step determines each system-level failure’s frequency occurrence (see Table 2). This data comes from the failure rates calculated in the course of the reliability prediction, which I covered in my two-part article “Product Reliability” (Circuit Cellar 268–269, 2012) and in “Quality and Reliability in Design” (Circuit Cellar 272, 2013).

TABLE 2
Use this information to determine the likelihood of each individual system-level failure.
Frequent Probability of occurrence per operation is equal or greater than 1 × 10–3
Probable Probability of occurrence per operation is less than 1 × 10–3 or greater than 1 × 10–5
Occasional Probability of occurrence per operation is less than 1 × 10–5 or greater than 1 × 10–7
Remote Probability of occurrence per operation is less than 1 × 10–7 or greater than 1 × 10–9
Improbable Probability of occurrence per operation is less than 1 × 10–9

Based on the two tables, the predictive risk assessment matrix for every hazardous situation is created (see Table 3). The matrix is a composite of severity and likelihood and can be subsequently classified as low, medium, serious, or high. It is the system designer’s responsibility to evaluate the potential risk—usually with regard to some regulatory requirements—to specify the maximum hazard levels acceptable for every subsystem. The subsystems’ developers must comply with and satisfy their respective specifications. Electronic controllers in safety-critical applications must present low risk due to their subsystem fault.

TABLE 3
The risk assessment matrix is based on information from Table 1 and Table 2.
Probability / Severity Catastrophic (1) Critical (2) Marginal (3) Negligible (4)
Frequent (A) High High Serious Medium
Probable (B) High High Serious Medium
Occasional (C) High Serious Medium Low
Remote (D) Serious Medium Medium Low
Improbable (E) Medium Medium Medium Low
Eliminated (F) Eliminated

The system safety assessment includes both software and hardware. For aircraft systems, the required risk level determines the development and quality assurance processes as anchored in DO-178 Software Considerations in Airborne Systems and Equipment Certification and DO-254 Design Assurance Guidance for Airborne Electronic Hardware.

Some non-aerospace industries also use these two standards; others may have their own. Figure 1 shows a typical system development process to achieve system safety.
The common automobile power steering is, by design, inherently low risk, as it continues to steer even if the hydraulics fail. Similarly, some aircraft controls continue to be the old-fashioned cables but, like the car steering, with power augmentation. If the power fails, you just need more muscle. This is not the case with the more prevalent drive- or fly-by-wire systems.

FIGURE 1: The actions in this system-development process help ensure system safety.

FIGURE 1: The actions in this system-development process help ensure system safety.

Redundancy

How can the risk be mitigated to at least 109 probability for catastrophic events? The answer is redundancy. A well-designed electronic control channel can achieve about 105 probability of a single fault. That’s it. However, the FTA shows that by ANDing two such processing channels, the resulting failure probability will decrease to 1010, thus mitigating the risk to an acceptable level. An event with 109 probability of occurring is, for many systems, acceptable as just about “never happening,” but there are requirements for 1014 or even lower probability. Increasing redundancy will enable you to satisfy the specification.
Once I saw a controller comprising three independent redundant computers, with each computer also being triple redundant. Increasing safety by redundancy is why there are at least two engines on every commercial passenger carrying aircraft, two pilots, two independent hydraulic systems, two or more redundant controllers, power supplies, and so forth.

Human Engineering

Human engineering, to use military terminology, is not the least important for safety and sometimes not given sufficient attention. MIL-STD-1472F, the US Department of Defense’s Design Criteria Standard: Human Engineering, spells out many requirements and design constraints to make equipment operation and handling safe. This applies to everything, not just electrical devices.

For example, it defines the minimum size of controls if they may be operated with gloves, the maximum weight of equipment to be located above a certain height, the connectors’ location, and so forth. In my view, every engineer should look at this interesting standard.
Non-military equipment that requires some type of certification (e.g., most electrical appliances) is usually fine in terms of human engineering. Although there may not be a specific standard guiding its design in this respect, experienced certificating examiners will point out many shortcomings. But there are more than enough fancy and expensive products on the market, which makes you wonder if the designer ever tried to use the product himself.

By putting a little thought beyond just the functional design, you can make your product attractive, easy to operate, and safe. It may be as simple as asking a few people who are not involved with your design to use the product before you release it to production.

Test Pixel 1