Design Article
Platform-level electrical systems development for aerospace
John Low, Integrated Electrical Systems Division, Mentor Graphics Corp.
2/10/2012 8:53 AM EST
Capturing design and mandate objectives
The business goal is to converge on a harnessing architecture as early in the design process as possible using initial systems and subsystems designs as input. The electrical systems and subsystems must be defined in a way that captures not only the connectivity data but also any design constraints to enable reuse of the systems data.
The ability to make trade-offs early in the design process allows the definition of a higher quality and better cost-to-weight solution. However, designers must be able to work very early in the process with the electrical platform to accomplish this instead of only focusing on individual electrical systems. Innovative tools provide the ability to analyze platform-level effects much more quickly. This shift in the design process helps to mitigate errors and reduce change costs.
A constraint is the basic building block of a digitally assisted decision process. It defines the simple construct of “If <this>, then <that>”. For example, an example of a EWIS mandate might be “If <EMC Cat=D>, then <route path = path acceptable for that EMC Cat>”. A constraint captures the design and/or regulatory intent in a form that can be algorithmically determined.
Of course, an engineer may decide to further refine a design decision that was defined automatically; however, the use of constraints drastically reduces the time it takes to obtain a defined core set of design decisions.
Managing constraints using algorithms captures the design and regulatory guidelines, as well as proprietary IP, within the tool. Constraints are essential to a platform-level development process. Constraints drive part selection, determine correct signal routing based on EMC compatibility, define splicing, implement grounding strategies, and enable consistency of results.
Developing the wiring systems architecture
Most COTS tools provide a means to graphically represent the system design. However, full-featured COTS tools provide the actual data underneath the picture in a way that also allows a complete description of the system and its constraints to accompany the graphic. For example, parameters such as power and signal characteristics, EMC classifications, and various other attributes can be automatically added to the high-level connectivity description.
Figure 2 depicts a systems design that defines not only the connectivity between devices but also a conductor’s properties, including its EMC classification and other system characteristics. Because this depiction contains underlying live data, it can be electrically validated using diverse methods such as qualitative analysis, sneak circuit detection, and FMEA.
Concurrently with the previous design, an engineer creates a topology roadmap (Figure 3) of the anticipated harness roadmap, typically before the 3D model is mature. This roadmap identifies areas in which devices from the systems schematics would be placed. The roadmap also contains information on possible signal routes based on the conductor’s constraints working in tandem with the topology constraints.
Given the systems information and properties and the topology roadmap and constraints, a first-pass wiring architecture can be synthesized, or generated, from the combination of the systems design model and the topology model. These synthesized wires have lengths dictated by the topology representation.
Maintaining a platform perspective allows the designer to refine the original wire size estimates using electrical analysis. The model data represents the true characteristics of the design objects so it’s possible to leverage the LRU and power characteristics defined in the model to do a platform-level analysis. Realistically, this analysis would be iterative as the platform integration takes place. The platform perspective provides the accurate context upon which to base analysis and refinement. With this perspective, engineers can easily model different harness architectures and evaluate them according to key metrics.
Next: Evaluating alternatives
The business goal is to converge on a harnessing architecture as early in the design process as possible using initial systems and subsystems designs as input. The electrical systems and subsystems must be defined in a way that captures not only the connectivity data but also any design constraints to enable reuse of the systems data.
The ability to make trade-offs early in the design process allows the definition of a higher quality and better cost-to-weight solution. However, designers must be able to work very early in the process with the electrical platform to accomplish this instead of only focusing on individual electrical systems. Innovative tools provide the ability to analyze platform-level effects much more quickly. This shift in the design process helps to mitigate errors and reduce change costs.
A constraint is the basic building block of a digitally assisted decision process. It defines the simple construct of “If <this>, then <that>”. For example, an example of a EWIS mandate might be “If <EMC Cat=D>, then <route path = path acceptable for that EMC Cat>”. A constraint captures the design and/or regulatory intent in a form that can be algorithmically determined.
Of course, an engineer may decide to further refine a design decision that was defined automatically; however, the use of constraints drastically reduces the time it takes to obtain a defined core set of design decisions.
Managing constraints using algorithms captures the design and regulatory guidelines, as well as proprietary IP, within the tool. Constraints are essential to a platform-level development process. Constraints drive part selection, determine correct signal routing based on EMC compatibility, define splicing, implement grounding strategies, and enable consistency of results.
Developing the wiring systems architecture
Most COTS tools provide a means to graphically represent the system design. However, full-featured COTS tools provide the actual data underneath the picture in a way that also allows a complete description of the system and its constraints to accompany the graphic. For example, parameters such as power and signal characteristics, EMC classifications, and various other attributes can be automatically added to the high-level connectivity description.
Figure 2 depicts a systems design that defines not only the connectivity between devices but also a conductor’s properties, including its EMC classification and other system characteristics. Because this depiction contains underlying live data, it can be electrically validated using diverse methods such as qualitative analysis, sneak circuit detection, and FMEA.
Figure 2: Systems design with conductor properties.
Concurrently with the previous design, an engineer creates a topology roadmap (Figure 3) of the anticipated harness roadmap, typically before the 3D model is mature. This roadmap identifies areas in which devices from the systems schematics would be placed. The roadmap also contains information on possible signal routes based on the conductor’s constraints working in tandem with the topology constraints.
Figure 3: Topology roadmap with routing constraints
Given the systems information and properties and the topology roadmap and constraints, a first-pass wiring architecture can be synthesized, or generated, from the combination of the systems design model and the topology model. These synthesized wires have lengths dictated by the topology representation.
Maintaining a platform perspective allows the designer to refine the original wire size estimates using electrical analysis. The model data represents the true characteristics of the design objects so it’s possible to leverage the LRU and power characteristics defined in the model to do a platform-level analysis. Realistically, this analysis would be iterative as the platform integration takes place. The platform perspective provides the accurate context upon which to base analysis and refinement. With this perspective, engineers can easily model different harness architectures and evaluate them according to key metrics.
Next: Evaluating alternatives
|
|
|
|
|
Navigate to related information