During the design phase of a commercial aircraft, designers have to respect the design principles from the ATA guidelines. Theses chapters are presented into multiple set of books and/or databases, making it hard for the designers to find the correct information.
Requirements Management, or “How to Ensure You Achieve What You Need” is something important for an airliner, stays however, very complex.
Despite its obvious advantages, generic coding creates problems for presentation. A fundamental problem is that the functional system context is spread out according to the spatially oriented classification. For example, most parts of the oil system such as accessories and pipes are covered in chapter 79-Oil, a few require chapter 73-Fuel, and the lubrication and cooling of bearings is covered in 72-Engine.The chapter breakdown in the tree diagram reveals the existence of an unacknowledged subsystem level expressed in a change of the second ATA number element (which stands for section). In terms of subsystem function, it is necessary to differentiate oil cooling as a sub-section of oil distribution. The aim of *DEASI *(previously *SIDP as a Database*) is to provide end-to-end support in the writing of theses requirements ensuring that the V&V process is validated.
The system should also feature a dictionary of items, natural language processing and quality checks, collaborative writing and direct connection with the most common data repositories of AIRBUS. This should ensure the respect of the Rupp's boilerplate, and thus it's understanding.
During my mission with the R&T team @AIRBUS, working side-by-side with their teams. We went through multiple iterations to understand their existing documentation, how it's managed and used.
- Concept & Design: Identifying the key ressources and business processes to use, model them and design an agile workload planning.
- Prototyping: During the early phase, prototyping was done along with writers and designers with spreadsheets and presentations. Once we evaluated the variety of contexts, including semantics, design, UI/UX, we used RAD tools to provide a real situation working PoC.
- Material, process and verification: Since the processes were complex, we discovered new ways to shrink them, and other ways to automate the most of them. We went through another iteration of coding, starting fresh to deliver a stable solution.
- Go Live: Rollout of the solution, in three steps:
- For writers in order to gather the information
- For designers to use it with their CAD tools
- For the Change Board (for in-process design rectifications, relaxations and request change notes)
For designers, it enables faster access to the right and up to date information, with schematics, explanations, 3D models and powerful criteria-based search engine.
- More documents cascading from the top level ATA chapters could be integrated. We performed tests with Technical Design Directives, Means and Tools and other manufacturing documents. We saw a real potential especially for tracking changes down or top stream.