NASA’s European Service Module safety team used Excel-based engineering tools to support Artemis II anomaly investigations, bringing component histories, failure analyses, and electrical-system information into a form engineers could search during flight. Three subsystem databases helped investigate unexpected behavior and inform decisions about whether the mission could continue safely.
The team describes that work in its technical conference presentation, Artemis-II In-Flight Anomaly Resolution Tool Development, Utilization, and Observations for Future Missions. The presentation documents two complementary implementations: ACEL-ENT, which retrieves engineering records, and a Power Distribution Architecture tool, which evaluates electrical connectivity and failure consequences.
Engineering Information Under Flight-Time Constraints
The presentation identifies a demanding operating condition: engineers could have less than two hours to evaluate an anomaly and determine its disposition during flight. That assessment required information about mission risk, possible causes, the consequences of another failure, and the documents supporting a decision.
The European Service Module contains Orion’s propulsion, electrical power, crew support, and thermal control systems. These functions connect directly to the spacecraft’s ability to sustain its crew and perform maneuvers. New Space Economy’s discussion of Europe’s contribution to Orion explains the division between the service module’s in-space support functions and the crew module’s role in returning astronauts to Earth.
An anomaly investigation can require several kinds of evidence at once. A component’s earlier test results may suggest a possible cause, a failure analysis may identify which consequences deserve attention, and flight rules may establish conditions requiring a particular operational response. The tools organized access to this information for the engineers supporting those decisions.
ACEL-ENT Connected Components With Their Records
ACEL-ENT stands for Artemis Collaboration and Elevated Localization Efficient Next-Failure Tool. The team created four databases in Microsoft Excel using Visual Basic for Applications, the programming environment used to automate tasks within the application. The databases covered propulsion, active thermal control, crew support, and solar generation.
Each database combined a clickable subsystem schematic, a three-dimensional system view, and searchable information categories. Selecting a component or a general information control applied filters to the underlying records. Engineers could move from the equipment under investigation to its relevant documentation without separately searching every source.
Three ACEL-ENT databases were used for in-flight Items for Investigation, the presentation reports. They retrieved records of previous nonconformances and acceptance documentation to identify potentially similar failures. They also provided failure modes and effects analyses, which describe how equipment can fail and what those failures can cause, along with flight rules specifying predeclared loss-of-mission conditions.
The authors report that faster information retrieval supported decisions about continuing the flight or aborting. Component histories also helped engineers recommend in-flight tests to better characterize the observed behavior. The databases supplied evidence to the investigation and decision process; mission personnel retained responsibility for evaluating that evidence.
Modeling Which Equipment Still Had Power
The Electrical Power System Power Distribution Architecture tool addressed another question: which equipment remained powered in a particular electrical configuration?
Implemented in Excel with Visual Basic for Applications, it represented the electrical system as a directed network. Components formed the network’s nodes, and connections identified the direction in which power could travel. Separate data tables described components, connections, and switch states.
A breadth-first search algorithm traced available paths from solar arrays and batteries to electrical loads, meaning the equipment consuming power. In plain terms, the search followed successive connections through the network to determine which destinations could receive electricity.
Engineers could configure switch states and represent powered or unpowered circuits to reflect the vehicle’s condition. The tool then helped identify equipment without power and assess the consequences of an additional failure.
That second question concerns remaining failure tolerance: how much additional failure the system can withstand before losing a required function or encountering a hazard. The presentation describes the tool as supporting assessments of current vehicle risk, the next worst failure, and the redundancy still available.
Comparing Flight Findings With Ground Tests
The presentation identifies in-flight investigations involving crew support, mechanical systems, and propulsion. These were investigated and endorsed by the Mission Management Team with authorization to continue the mission.
After flight, the team compared the findings with ground nonconformances and reviewed possible causes using fishbone assessments. These assessments organize candidate causes into categories so investigators can examine evidence and existing verification coverage systematically.
For crew support, the review considered force margins, installation damage, material integrity, and corrosion. Mechanical-system investigations considered command behavior, motion specific to individual units, and interactions between systems. Propulsion investigations examined dimensional tolerances, material compatibility, and static seals.
The authors report that the acceptance-test strategy was validated without significant gaps. They also describe continuing work to reassess risk, confirm design tolerance, and investigate targeted screening for particularly susceptible hardware. Those activities distinguish the reported assessment of the existing test strategy from proposed additions to it.
Supplier Records and Database Maintenance
ACEL-ENT did not contain all the information needed for the investigations. Records from lower-tier suppliers required supplemental requests, including requests after flight. Depending on the system, the missing material included component testing, inspections, manufacturing-lot information, structural analyses, procurement records, and material-compatibility test data.
Maintaining the tools also required substantial manual work. The databases had to be repopulated for each mission to account for differences between vehicles. Supplier documentation lacked consistent formatting, and some documents could not be searched effectively.
The authors recommend making safety-critical component information from lower-tier suppliers available on request during flight to support go/no-go decisions. They also recommend more consistent acceptance-documentation formats and better optical character recognition, which converts text in scanned pages into searchable characters.
A further recommendation is to investigate artificial intelligence for adding information to existing databases and searching a shared repository. The presentation assigns interpretation to the responsible engineer. It describes these capabilities as proposed improvements to data compilation and retrieval, with the documented Artemis II implementations remaining the Excel-based tools.
