TriVector Verifies Time Latencies for Ares I Rocket
“Our SimEvents model for Ares I tracks delivery time for approximately 20,000 packets per second across multiple buses, enabling us to validate requirements and identify issues with the timing requirements prior to hardware design.”
Challenge
Solution
Results
- Requirements validated one year sooner
- Timing specification problems uncovered
- Latency analysis results communicated visually
The Ares I rocket is central to NASA’s Constellation Program missions to the International Space Station, the moon, Mars, and the solar system. There are two stages to Ares I: In the First Stage, a reusable Solid Rocket Booster lifts the Orion crew vehicle toward low-earth orbit during launch before separating from Ares I. In the Upper Stage, a single J-2X engine propels Orion into orbit. Communication between avionics systems on the two stages, Orion, and Ground Systems is critical to the success of each launch.
In support of NASA, the TriVector Services Team analyzed the timing of more than a dozen Ares I communications buses. By performing discrete-event simulation of Ares I packet-level communications using Simulink®, Stateflow®, and SimEvents®, engineers assessed network latency and verified requirements for the buses before any hardware or software was developed.
“The Ares I buses carry health and status information from avionics sensors to flight computers, Orion, and Ground Systems,” explains Kerry Alexander, senior engineer at TriVector. “With SimEvents, we ran simulations that tracked each packet from its source to its destination and verified that it was delivered within the time frame required by NASA.”
Challenge
To analyze timing and verify requirements, TriVector engineers needed to model the Ares I communication system architecture and simulate transactions between components. The model had to include each RT, the buses, and their interconnections. The team had to run simulations at the microsecond level and then postprocess the results to measure latency. Finally, they needed to graphically represent the analysis results to prove that timing requirements could be met.
Because the hardware had not been developed, the engineers had to model the system based solely on requirements.
Solution
TriVector engineers used Simulink and SimEvents to simulate packet-level communications throughout Ares I and to analyze end-to-end latency of health and status information.
They built a model of the Upper Stage buses and RTs based on a data I/O profile from NASA that included a data schedule defining when the flight computers would request data from the RTs in subsecond time slices.
They used their initial SimEvents model, which included one RT, a flight computer, a bus, and the system clock, to simulate the delivery of data at a specified time slice. They then added RTs and other components until they had modeled the Upper Stage low-rate data buses.
With SimEvents, the engineers calculated the latency for each packet delivered by comparing the time the packet originated from the RT with the time the packet arrived at its destination.
Using Stateflow, the engineers modeled signal logic in the Upper Stage flight termination system, which is used to destroy the rocket in the event of an emergency.
TriVector worked with MathWorks consulting services to implement best practices for large-scale modeling. They built a library of parameterized, reusable components based on SimEvents blocks that made the model easier to modify and shortened simulation times.
The team further accelerated simulations by using Simulink Coder™ to create a standalone executable.
The team used MATLAB® to postprocess the simulation results and create plots of packet latency.
The TriVector Services Team has completed the initial timing analysis for Ares I, including First Stage and Upper Stage buses. The team is now using Requirements Toolbox™ to trace requirements captured in Microsoft® Word® to the model.
Results
Requirements validated one year sooner. “By modeling discrete events with SimEvents we were able to simulate packet-level transactions well before hardware was available,” says Alexander. “If NASA had to build hardware first, verification of the timing requirements could have been delayed by a year.”
Timing specification problems uncovered. “Our SimEvents model provided a picture of the entire system as well as detailed timing results that would have been impossible to obtain using a spreadsheet,” says Alexander. “This approach enabled us to report missing requirements to NASA for refinements.”
Latency analysis results communicated visually. “We created MATLAB plots that made it much easier to visualize and communicate our results,” notes Alexander. “For example, we graphed the time latency requirement for each packet on a particular bus in a five-second simulation as a red line; on the same chart, we graphed the actual latency for those packets. When all packets were below the red line, we knew the system met a particular requirement.”
