DFLO

Why aerospace is a data problem

An aircraft is a physical object, but almost everything an organisation knows about one is a record. Its configuration — which components are fitted, to which standard, with which modifications — is a record. What was done to it last week, and by whom, is a record. What it did on its last flight, what it is due for next, and whether the part sitting in the store is the right one, are all records. Lose confidence in those, and the aircraft has not changed at all, but what can safely be done with it has.

That is the sense in which every aerospace environment needs data management. It is not a back-office convenience: the records are how the physical state of the fleet is known at all.

Accurate and fast, and why it has to be both

The company’s own description names two requirements, and the interesting thing is that they pull in opposite directions.

Accuracy is a correctness requirement. A record that is wrong is worse than a record that is missing, because a missing record announces itself and a wrong one does not. Accuracy is bought with validation at the point of entry, a single agreed order of events, and refusal to accept an entry that contradicts what is already committed — the alternative being two plausible histories and no way to tell which is true.

Speed is a usefulness requirement. Data that is correct but arrives after the decision has been made did not contribute to the decision. In an operational environment the question is almost always “what is true right now”, and an answer that takes a day is an answer to a different question.

The tension is real: the cheapest way to be accurate is to check everything slowly, and the cheapest way to be fast is to accept everything and sort it out later. Neither is acceptable here, which is why the two requirements are stated together rather than one at a time.

What a record has to carry

The section below describes what any operational record in this domain has to establish, rather than the specific fields DFLO holds.

A record that cannot answer all of the following is not a record of very much:

• What happened or was done, in terms specific enough that someone who was not present can tell what state the thing is now in.
• When — not merely the date it was written down, which is a different fact and frequently a later one.
• Who did it and who accepted it. Accountability that cannot be traced to a person is accountability in name only.
• To which item — the individual aircraft or component, not the type. A type tells you what something is; a serial number tells you which one you are holding.
• Against which configuration — the standard the item was at when the work was done. The same task against two different build standards is two different pieces of history.

The last two are where record-keeping most often quietly fails. Data that is accurate about the wrong aircraft, or right about an aircraft in a configuration it is no longer in, reads as perfectly good data until the moment it matters.

One record, many readers

The same entry is read by people asking quite different questions, and a data layer earns its keep by serving all of them from one copy rather than from three.

Engineering at Plavata reads history to find out how a design behaves once it leaves the bench — what actually wears, what gets adjusted in the field, what the drawing did not anticipate. Ground support at JCB reads it to know the condition an aircraft is arriving in and what it needs before it leaves. Maintenance reads it through Fleet Record to establish the state of an aircraft and what is due next.

Three readers, three questions, one underlying record. The moment each of them keeps their own copy — because the shared one is slow, or awkward, or does not have the field they need — the organisation has three histories and no way to reconcile them. That is the failure the accuracy and speed requirements are both ultimately defending against.

Where it sits

DFLO is the layer the rest of the company’s work is recorded into and read back from. Engineering at Plavata produces configuration that has to be known accurately for the life of the airframe; ground support at JCB generates work that has to be recorded as it happens; and maintenance is recorded through Fleet Record, whose whole discipline rests on there being exactly one history per aircraft.

Enquiries about DFLO, including access, go to info@bengalaerospace.com.