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
Managing more electrical data
Much of the system information that exists at an early stage can be used to define and evaluate harness architecture alternatives. Electrical systems and their connectivity are defined early in development, most often using functional and logical schematics from the OEM platform team or individual system suppliers. Performance requirements such as zoning for temperature rating or EMC class will also have been described. Information relating equipment placement and geometric constraints defining the routing of the wire harness is available. Performance details of every component are known early and can be stored in a library for reuse. COTS tools, such as Mentor Graphics’ Capital system, provide these definitions, specifications, and requirements in a form that is useful for performing platform-level engineering tasks.
If COTS tools are to effectively support the needs of the aerospace community, they must be able to manage options/variants, effectivity and mod kits, and must have knowledge of and control over data maturity. The platform perspective a designer needs might be a combination of baseline design content and some optional or kit-installed content. The designers’ confidence that they will be able to quickly assemble all the specific data for a given platform is of paramount importance. Leading COTS tools provide comprehensive user and data management capabilities, which is an important part of regulatory compliance.
Having a common repository of design data will ease the challenges of all the stakeholders. For example, if manufacturing planning could reuse the data from design engineering, then automated tasks like terminal/seals/plug selection, calculation of manufacturing wire lengths, and many other tasks can be accomplished. Decisions made in one domain are consistent and congruent with decision criteria from other domains because of this common data stream.
Progressing along this flow, the harness production data evolves into shop floor deliverables to support the harness build activity. Using the same data assets in the database for these downstream activities eliminates errors caused by data re-entry.
The platform perspective provides a much more accurate context upon which to base analyses and refinement. With this perspective, design engineers are able to easily model different harness architectures and evaluate them according to key metrics.
Managing a complex change environment
Wiring design has traditionally been a downstream, late-stage activity. However, potential problems can actually start early. This is because the mechanical design of the platform, which is a key partner in electrical design, is quickly maturing while the electrical systems development is still relatively early in its definition phase.
Electrical design typically has one of the highest rates of change as compared with other design domains [4]. As changes ripple through the electrical design phase, their effect on the mechanical environment can be significant. Even the communication of the change is often challenging because of internal organizational dynamics. Many companies are organized into vertical silos of engineering teams, and decisions made by one team are handed over-the-wall to another team to evaluate, understand, and plan for. A means to share the data and design constraints that will eventually affect the engineering team consuming the data is needed to reduce the number of design changes.
In the past, it has often been difficult to produce an accurate, early stage specification for the harness architecture because there hasn’t been a good way to embed design constraints with all of the data that can be shared across multiple engineering domains. The result is an initial specification followed by repeated changes. The problem is that every change costs money and the architecture that results may not be ideal from a cost and weight perspective.
The platform-level approach enables a designer to work with a specific set of electrical definition while interacting with other emerging systems elements; in this way, the design engineer can tackle each challenge with the wider view of the platform, allowing him or her to see how specific design aspects and changes affect other systems.
Much of the system information that exists at an early stage can be used to define and evaluate harness architecture alternatives. Electrical systems and their connectivity are defined early in development, most often using functional and logical schematics from the OEM platform team or individual system suppliers. Performance requirements such as zoning for temperature rating or EMC class will also have been described. Information relating equipment placement and geometric constraints defining the routing of the wire harness is available. Performance details of every component are known early and can be stored in a library for reuse. COTS tools, such as Mentor Graphics’ Capital system, provide these definitions, specifications, and requirements in a form that is useful for performing platform-level engineering tasks.
If COTS tools are to effectively support the needs of the aerospace community, they must be able to manage options/variants, effectivity and mod kits, and must have knowledge of and control over data maturity. The platform perspective a designer needs might be a combination of baseline design content and some optional or kit-installed content. The designers’ confidence that they will be able to quickly assemble all the specific data for a given platform is of paramount importance. Leading COTS tools provide comprehensive user and data management capabilities, which is an important part of regulatory compliance.
Having a common repository of design data will ease the challenges of all the stakeholders. For example, if manufacturing planning could reuse the data from design engineering, then automated tasks like terminal/seals/plug selection, calculation of manufacturing wire lengths, and many other tasks can be accomplished. Decisions made in one domain are consistent and congruent with decision criteria from other domains because of this common data stream.
Progressing along this flow, the harness production data evolves into shop floor deliverables to support the harness build activity. Using the same data assets in the database for these downstream activities eliminates errors caused by data re-entry.
The platform perspective provides a much more accurate context upon which to base analyses and refinement. With this perspective, design engineers are able to easily model different harness architectures and evaluate them according to key metrics.
Managing a complex change environment
Wiring design has traditionally been a downstream, late-stage activity. However, potential problems can actually start early. This is because the mechanical design of the platform, which is a key partner in electrical design, is quickly maturing while the electrical systems development is still relatively early in its definition phase.
Electrical design typically has one of the highest rates of change as compared with other design domains [4]. As changes ripple through the electrical design phase, their effect on the mechanical environment can be significant. Even the communication of the change is often challenging because of internal organizational dynamics. Many companies are organized into vertical silos of engineering teams, and decisions made by one team are handed over-the-wall to another team to evaluate, understand, and plan for. A means to share the data and design constraints that will eventually affect the engineering team consuming the data is needed to reduce the number of design changes.
In the past, it has often been difficult to produce an accurate, early stage specification for the harness architecture because there hasn’t been a good way to embed design constraints with all of the data that can be shared across multiple engineering domains. The result is an initial specification followed by repeated changes. The problem is that every change costs money and the architecture that results may not be ideal from a cost and weight perspective.
The platform-level approach enables a designer to work with a specific set of electrical definition while interacting with other emerging systems elements; in this way, the design engineer can tackle each challenge with the wider view of the platform, allowing him or her to see how specific design aspects and changes affect other systems.
|
|
|
|
|
Navigate to related information