ATP
Defining Subsystems and End Articles
Any complex system, such as an aircraft, automobile, or factory, can be thought of as a collection of several smaller systems of somewhat less complexity, that provide important functions such as propulsion (engines, robotics), information and control (instruments, avionics), fuel delivery, and so on. Let’s call the smaller systems “subsystems” for the purpose of this blog post, and we’ll call the resulting complex system the “end article”. The subsystems fit together, or are “integrated” with the end article or with each other, and need to communicate with each other so that the end article can do its intended work or mission. There is also an interdependence or reliance between these subsystems, such that a failure or degradation in performance in one of the subsystems often affects the performance of the end article, and potentially sibling subsystems as well.
End Articles
Modern end articles are created by a top-tier systems integrator, who functions as the architect, and who is responsible for selecting the subsystems that comprise the end article. The integrator considers the performance, reliability, safety, and cost of each subsystem, the time, cost, and effort to maintain and support the subsystem, as well as other lifecycle aspects when selecting the subsystem. Documentation, warranty and other support elements associated with the subsystem are often integrated into the overall logistics of the end article.
Subsystems
Subsystems (engines, instruments, etc.) are typically products that are fitted to many different types of equipment (end articles), with relatively minor configuration changes. In this way, a single jet engine design could be adopted by multiple aircraft manufacturers but would interact differently with each aircraft, depending on each architect’s design concept.
The Challenge With Troubleshooting The End Article
Given the highly integrated nature of the end article, such as an aircraft, and its subsystems, at multiple levels – communications, fuel delivery, mechanical fit, electrical connections, documentation, warranty – a logical case can be made for fitting together the originating aviation troubleshooting guidance, as well as field knowledge or experience gained from the actual use of the end article with its related subsystems. This adds yet another dimension to the integrated logistics system concept. We’ll call the fitting together of one or more of these troubleshooting databases a “federation” of databases, for the purposes of this blog.
There is no question that a company that manufactures and supports its own products (subsystems) has the deepest and broadest expertise on those products. And, of course, each manufacturer maintains a repository of its own engineering and field knowledge to assist customers with troubleshooting. However, when subsystems from several manufacturers are combined, such as an engine on an aircraft, the technician faces a dilemma: where does the technician go for the best troubleshooting guidance – to the aircraft, or to the engine – when the problem could be on either side?
The end article manufacturer also faces a dilemma: should they copy, convert, and update their supplier’s troubleshooting guide for the life of the product, or should they send their customers to the subsystem vendor when troubleshooting arises? If they do the latter, will they lose the feedback from their valued customers? The federation of support databases, particularly troubleshooting data, is an elegant solution to this dilemma.
In fitting together this supporting knowledge in a useful way a number of additional aspects must be considered.
Support Knowledge Considerations
OEM and Vendor Intellectual Property (IP) rights
In this highly competitive world, OEMs and major subsystem vendors compete amongst each other for very slight advantages at the end article level. Subsystems are possibly even more exposed to competitor presence, by the sheer presence of more vendors at the subsystem level, and therefore more competitor pressure. The data created during the capture and assimilation of field experience, which stems from faults or failures in the field, is particularly sensitive to any participant, and potentially damaging to the parties concerned. Legal and financial concerns abound, so it is, therefore, crucial that a federated database is rock solid with respect to limiting IP exposure, and respects the business needs of all joined parties.
Connectivity and Accessibility
The federation or joining together of support databases from two or more corporations on a single project carries with it the need to bridge two or more corporate cultures at the data sharing level. Disparate information systems and technology policies come into play as practical barriers to be overcome, so that the resultant federated database satisfies everyone’s requirements. The approach may entail delicate negotiation and compromises, with diligent and expert guidance needed to realize the federation goals.
Security and Export Controls
While the security and export control of data is always a primary consideration in making data available to end-users, the possibility of breaching controls expands exponentially, as more parties are joined or federated for the same support database. Conceivably a subsystem may entail no export controls whatsoever, as a stand-alone system or product, but within a federated system, given that the supporting data could give clues to say, deployment location or performance capabilities of the end article itself, the subsystem could create a security concern.
Selective Access
Closely allied to security, export controls and the protection of IP is the need to deliver support content depending on who is requesting data from the database. If, for example, the user is internal to the subsystem vendor, then database access will likely be unrestricted, providing visibility to sensitive data that would not be seen by, say, the end article integrator, and certainly not by an end-user.
Overcoming the Challenges of End Article Troubleshooting
Overcoming the challenges of end article (system-level) troubleshooting is not easy, but it is extremely important. As cross-system defects propagate fault codes from one subsystem to another it is difficult for the top-tier system integrator to assemble all the troubleshooting guidance into a coherent set of tests and procedures. Federating the troubleshooting databases allows the diagnostic processes for each subsystem to be optimized independently and then presented as an integrated whole. This allows the service technician to seamlessly transition from one subsystem database to another as each test and observation guides the troubleshooting process toward the root cause and resolution. The result is a fully-capable, mission-ready diagnostic environment that is up-and-running in less time, provides expert guidance to field technicians and call-centers, protects the intellectual property of subsystem vendors, and captures important field experience for in-service performance monitoring and corrective actions.
About ATP.
ATP is the leading provider of aviation software and information services.
Our innovative product lines, including Flightdocs, Aviation Hub, ChronicX, and SpotLight, reduce operating costs, improve aircraft reliability, and support technical knowledge sharing and collaboration in all aviation and aerospace industry sectors.
The products and services of ATP support more than 75,000 aircraft maintenance professionals worldwide. As a global company, ATP has more than 7,500 customers in 137 countries and partnerships with over 90 OEMs.