NASA's Ares I rocket.
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 MathWorks’ 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.”
A Timing Challenge
Both of the Ares I elements—the First Stage and the Upper Stage with J-2X Engine—have redundant buses linking flight computers to remote terminals (RTs), which collect avionics sensor data. Top-level requirements from NASA specify that once data is acquired by an RT, the data must be delivered to Orion or Ground Systems within a specified time; lower-level requirements specify the timing for element-to-element data delivery.
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.
Simulink debugger GUI used with a multirate control system. Users can step through the simulation one method at a time or run to breakpoints
Because the hardware had not been developed, the engineers had to model the system based solely on requirements.
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.
Use Simulink and Stateflow to simulate and study the effects of switching modes on the control system and aircraft dynamics
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 Real-Time Workshop 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 Simulink Verification and Validation to trace requirements captured in Microsoft Word to the model.
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 Kerry Alexander, senior engineer at TriVector. “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.”