A look at automated design tools to simplify EWIS compliance

  • 28-May-2010 02:23 EDT
Figure 1 - FMEA.jpg

Several relevant analysis panes from the Mentor Graphics Capital Design suite, annotated to explain the graphical display capability, are depicted. The example shows various failures ranked in order of Risk Priority Number (RPN). The RPN value of 60 implies an error that requires attention; the failure is preventing the Caution Advisory Panel (CAP) from displaying messages in the cockpit. The schematic highlighting immediately reveals where in the design the failure occurs and the failure’s effect.

Some form of regulation or standard applies to virtually every bolt, panel, and wire in a modern aircraft. Some of the most demanding regulations relate to the craft’s Electrical Wiring Interconnect Systems (EWIS). These compliance requirements can have a huge impact on cost if not anticipated from the very beginning of an aircraft design project.

By incorporating EWIS regulations in the earliest phases of the project, and using same to support astute design decisions, it is possible to avoid most of the late-phase design changes and corrections. Postponing the compliance checks can mean making changes when they are most costly.

EWIS is now part of the Federal Aviation Regulations (FAR) Part 25 mandates and therefore a condition of certification for all new commercial aircraft. “EWIS thinking” has bridged over to other industries including rotorcraft and defense platforms. Mentor Graphics has identified several areas of concern, as well as ways in which COTS electronic design automation tools can help designers achieve EWIS compliance.

Naming conventions

FAR 25.1711 describes the type of identification and information that EWIS components must carry. Included are such things as the component’s function, redundancy considerations, separation requirements, and uniqueness. Since the component identification must resolve to one and only one occurrence of that identification in the aircraft, this rule must be followed throughout the entire life cycle of the aircraft.

For example, assume that a wire name is composed of the harness identification, a separation category, a counter specific to that harness, and the wire gauge—say, wire number W238- FC1-101-22. The uniqueness requirement stipulates that there cannot be another W238-FC1-101-22 identified wire in that harness or anywhere else in the vehicle.

Today the sheer number of EWIS components in an aircraft, the diverse aircraft configurations, and the life-cycle change-management challenges make this task arduous and very prone to error. A more systematic and more automated methodology is needed.

One simple solution would be to check electronically for duplicate object names at various points in the design cycle. But this might allow an error to ripple through the process and affect connectivity or documentation elsewhere in the airplane.

In contrast, advanced COTS tools follow a “correct-by-construction” methodology. Instead of allowing the user to create an invalid condition and then relying on a subsequent check to find it, the software prohibits it from occurring in the first place. As the designer creates design data, the COTS tool applies the wire naming rules to ensure that the EWIS objective is met, automatically enforcing compliance with FAR 25.1711.

Safety matters

FAR Part 25.1709 focuses on EWIS system safety. The requirements ensure that a catastrophic failure is extremely improbable and will not result from a single failure and that the likelihood of every conceivable hazardous failure condition is extremely remote.

Fault-Tree Analysis and Failure Modes and Effects Analysis exemplify virtual modeling capabilities. Software tools that perform these types of analyses require current design data, and staying in step with changes can be a huge challenge. Electrical designers mature their data with deadlines in mind, and safety engineers can’t afford the time to re-enter new data each time an analysis is needed.

The best solution for this conundrum lies in a safety analysis toolset that is integrated within the design environment, which enables expedient reuse of information and leverages the design data into applications that serve the larger project objectives. Ideally, safety-analysis tools must do more than just provide “data” about safety implementation. They also must provide a means to quickly evaluate the impact of their analysis and to assist the design engineer in making changes efficiently.

Until recently most analysis tools have issued results in text form, which burdens the safety engineer with determining what issues are most critical. But modern COTS design and analysis tools are integrated into a single seamless environment.

Up-to-date electrical design data is always available to reuse for a variety of purposes, including EWIS safety compliance analysis. The analysis innately works on the current state of the design data. Moreover, that data can be manipulated to show graphically where problems may be occurring.

Enforcing the rules

EWIS mandates include a host of rules expressing requirements. For example, each component must “…be of a kind and design appropriate to its intended function” and “…independent electrical sources must not share a common ground.” These types of mandates can be addressed within the COTS toolset by capturing the core requirements as design rules and constraints.

Design tools can impose rules and constraints to assist and automate much of the decision making. There are clear advantages to this approach in that the toolset makes decisions quickly and automatically, it delivers consistent results over the span of many similar decision points, for each decision it is easy to assess the resulting cross-domain impact, and there is innate traceability of every factor that went into the decision and how the choice was made.

The basic building block of a digitally assisted decision process is the notion of a constraint. A constraint defines a simple construct such as "if-then." This example limits the proximity of wires carrying signals that might interfere dangerously with each other.

Essentially a constraint captures the design and/or regulatory intent in a form that can be algorithmically determined. The use of constraints can drastically cut the amount of time needed to get the core set of design information defined.

Rules, also known as constraint rule sets, are simply sets of constraints that are grouped together for a specific purpose. Early in the harness architecture stage, the engineer creates a topology roadmap of the anticipated harnessing before the 3-D model is mature and then defines the necessary rule sets and constraints. The constraints ensure that the electrical parts are automatically located in the appropriate areas, with wires routed and splices placed correctly.

EWIS mandates do not enforce any one particular solution, so the designer is free to apply his/her judgment based on the analytical data. A designer can explore innovative design alternatives with confidence that requirements are indeed being met.

Design 'domains'

EWIS rules do not demand adherence to one narrow solution. Their lack of specificity can challenge designers who are accustomed to dealing with minute details. Consider FAR 25.1703(4): “Each EWIS component installed in any area of the aircraft must be designed and installed in a way that will minimize mechanical strain.”

Like many EWIS mandates, FAR 25.1703(4) is a cross-domain requirement. It may have consequences relating to the design, verification, and installation domains and more—all of which must be aware of each other and synchronized.

Determining whether a wire bundle meets EWIS requirements calls for an understanding of many factors—not just the knowledge that it is a bundle. Suppose the MCAD designer models the bundle simplistically as a tube of a certain diameter. Conceptually this element can be positioned and routed but there is no information to guide appropriate decisions about slack, backshell entry conditions, and so forth. It is essential to know the details of the elements within the bundle.

The solution to this issue is an integrated cross-domain design environment. Integrated data communication between the ECAD and MCAD design realms dramatically simplifies the engineer’s work by automatically correlating a change in any domain with its “ripple effects” in all domains.

This article was written for Aerospace Engineering by John Low, Aerospace Business Development Manager, Integrated Electrical Systems Division, Mentor Graphics Corp.

HTML for Linking to Page
Page URL
Rate It
0.00 Avg. Rating

Read More Articles On

Connectivity spawns need for security designed-in from the beginning, a complex issue that spans many disciplines.
SAE International is working with the joint-venture initiative looking to deploy a high-powered DC fast-charging network for battery electric vehicles (BEVs) covering long-distance travel routes in Europe.
Researchers from Iowa State University are expanding fundamental materials studies into research and development of new, all-solid-state technology for batteries.
Imperial College London researchers are working on technology that could allow drones to stay airborne indefinitely simply by hovering over a ground support vehicle to recharge.

Related Items

Training / Education
Training / Education