Close Advertisement

SYSTEM DEVELOPMENT

WEB EXCLUSIVE: Three Stage Process Speeds Path to Avionics System Deployment

There are right and wrong ways to move an avionics system from development to deployment in an effective way. By following a three stage method, engineers can same time and cost.

WAYNE MCGEE, VP AND GENERAL MANAGER CES--NORTH AMERICA

Keywords in this Article:

No Keywords

  • Page 1 of 1
    Bookmark and Share

Article Media

 

WEB EXCLUSIVE: This article was selected as a special web exclusive preceding its print debut. It will also appear in an upcoming print issue of COTS Journal.

The traditional development process involves three separate stages to get to a deployable system. The first stage gathers the requirements for the system including the deployment environment, functional requirements, performance requirements and CPU headroom. The type of certification (commercial or military), certifying body (FAA, ESA, etc) and level of criticality (Design Assurance Level) are also taken into account. With the completed requirements documents in hand the next step is to build a lab or proof of concept model using as many commercial off the shelf (COTS) as possible to approximate the final system configuration. The examples shown here depict 3u VPX and are applicable to 6u VPX and VNX as well.

Frequently these are air-cooled system that will never be subjected to the actual deployment environment and will be used to develop and do initial testing of the software. Using COTS boards allows engineers to focus on developing hardware functions or sensor interfaces that are not available commercially. At this stage, cabling and connectorization usually does not even closely resemble the final system. As the missing pieces are made available the system integration effort gets underway. The application software is added and debugged.

Iterative Development

As the system becomes functional, performance testing begins. This is an iterative phase as mistakes are uncovered and fixed and the degree that the system meets all of the requirements is determined. If the system requires safety certification any changes to the design must be integrated into the certification package and comply with the original plan. Figure 1 shows an example of a lab system with prototype cabling.

Figure 1
At the proof-of-concept phase cabling and connectorization usually does not even closely resemble the final system.

After the proof of concept lab system has been fully debugged, tested and characterized, the pre-flight stage starts. The air-cooled assemblies are redesigned or replaced with ruggedized conduction cooled extended temperature models with all of the changes required in the first stage incorporated. A conduction cooled chassis replaced the air-cooled version and rugged connectors replaced the commercial versions. This in and of itself creates a more difficult situation for cabling as custom cables must be fabricated at this point using far more expensive wiring and connectors.

EMI and Protection Circuitry

The PCB on the chassis with the mating connectors must now support any EMI and protection circuitry that would be needed in the deployment environment. If there are hold-up requirements on the power supply this must now be implemented. After all of the redesigned subsystems are available and integrated, the testing gauntlet begins in earnest. Extensive temperature cycling, shock and vibration and EMI testing are performed.

It is not uncommon for these tests to reveal weaknesses not previously seen and measures taken to eliminate the issues. As this version of the hardware more closely resembles the final version, more rigorous testing of the software and performance are performed including deliberate fault injection to test BIT coverage and fault recovery mechanisms. As the second stage draws to a close all of the changes must again be rigorously documented in preparation for the final stage.

For the production stage, all of the previously implemented changed are put through even more rigorous testing to prove the system hardware and software perform per the spec. Fault resilience and BIT performance are exercised thoroughly. The certification documents with evidence and artifacts are put into final form and delivered to the next level in the vehicle integration chain. The process described here can take between three to five years, especially where higher Design Assurance Levels are required. So the question to be asked is how do we reduce the time, effort and cost to get to the production stage without introducing additional risks? How do we show higher Technology Readiness Levels (TRL) earlier in the development process?

Shop Replaceable Units

In order to shorten the development cycle you need to start with a collection of Shop Replaceable Units (SRUs) that would be used in all stages of the development. These SRUs must provide most of the functionality needed for the end system. These would, of course, be conduction cooled, not air-cooled. For ease of use in the laboratory you would need a chassis that uses the exact same backplane as the deployment chassis, but would use a commercial power supply and connectors. It would be internally conduction cooled for the payload but externally air-cooled for use in the lab. This allows the system to be quickly configured using standard commercial cabling prior to final selection of the final rugged connectors and pinout assignments.

The SRU collection should include the SBC, an Avionics I/O module capable of providing the most common interfaces as well as a graphics module with sufficient capture, render and display capability. Other interface needs could be addressed using available XMCs and carrier cards. By utilizing this approach, much of the second stage of integration and testing is eliminated. Figure 2 shows an example of lab chassis with various commercial connectorization.

Figure 2
Shop Replaceable Units (SRUs) provide most of the functionality needed for the end system. Shown here are SRUs with various commercial connectorizations.

Deployable Chassis

Once the payload has been characterized in the above-mentioned chassis the payload and backplane can be migrated to the deployable chassis. Here the lab power supply is replaced with the final supply with hold-up capacitors if required. The interface board with commercial connectors is replaced by one with the appropriate rugged connectors.

Depending on the deployment requirements various circuits for signal conditioning, EMI and lightning protection would be implemented on the connector board or an interposing board prior to connection into the backplane. Figure 3 shows an example of the final deployable chassis. At this phase all of the final environmental testing can be completed and flight testing can begin.

Figure 3
Shown here is an example of the final deployable chassis on which final environmental testing can be completed and flight testing can be done.

Savings Using this approach it is estimated that you could take six to twelve months off of the development schedule, reducing both the risk and the cost of the project. When reusing the building blocks for subsequent projects the savings on the BSP, drivers and BIT software is significant.

Putting SRUs to Good Use

By combining elements of the laboratory and pre-flight stages with reusable SRUs you can eliminate some of the redundant integration and testing required to move from the initial stage to the next. By selecting SRUs that cover the most common functions required in an Avionics Mission Computer the building blocks can be reused on similar projects. The use of these common SRUs also boosts the Technology Readiness Level by allowing quick demonstration of functional systems.

CES (Creative Electronic Systems)
Geneva, Switzerland
+41 (0)22 884 51 00
www.ces-swap.com

 

LEAVE A COMMENT