Service · Performance Databases

SCAP Databases Services

We create our own SCAP performance databases — and we built the tools that make it possible. Graphite reads an AFM the way an engineer reads it: it finds the figures, works out what each one certifies, and captures the thousands of points behind every curve at a precision no hand-plotted reading can reach.

SCAP takeoffSCAP landingAFM digitising Curve captureFull float precisionValidation

Why this exists

The database is the aircraft, as far as your software is concerned.

Every takeoff and landing number an operator computes comes out of a performance database. When that database is missing a case, stops short of the envelope certified in the AFM, or does not exist for your aircraft at all, an operator is usually told nothing can be done.

Something can be done. We create our own SCAP databases — and we built the tools that make it possible.

Capabilities

What do we do with the databases?

01

Takeoff performance

Maximum takeoff weight and V-speeds against the runway as it really is — and against what stands beyond the end of it. Obstacle clearance is computed from the obstacles of that aerodrome, not assumed away by a generic gradient.

02

Landing performance

Maximum landing weight and certified landing distances, normal and non-normal, with the approach speeds that go with the configuration actually being flown.

03

Engine out procedures

The escape path when an engine quits on departure — built on the same certified database, so the procedure and the takeoff weight it permits come from one source rather than two.

And it can be delivered however the operation runs. The same tooling drives runway analysis on a stand-alone workstation, the same thing web based, regular per-airport performance charts, or our own eLila EFB on the iPad. One database behind all of them.

The tool

Graphite

An AFM is thousands of printed curves, and every performance number an operator will ever compute traces back to how faithfully those curves were read. So we wrote the software that reads them.

It reads the manual before we do

Graphite scans the AFM, parses its own table of contents as ground truth, and identifies which figures the manual actually contains. Each one is classified against what the regulation requires — WAT limit, approach climb OEI, landing climb, VREF, VAPP and VGA, landing distance dry, wet and gravel, tyre speed and brake energy — and anything it cannot place is flagged for review rather than quietly skipped. The result is a coverage report: what this AFM certifies, and what is missing.

It knows whose manual it is

Manufacturer, model, engine, certifying authority, document number and revision are read out of the AFM’s own headers and footers. A database is only as traceable as the paper behind it, so the paper is identified before a single point is taken.

Capture at a fraction of a pixel

Axes are calibrated against known reference points, linear or logarithmic, with the orientation detected from the points themselves. Curves are traced automatically or taken by hand with a live magnifier and a calibrated readout, nudging in increments as fine as a twentieth of a pixel. On a chart spanning 40,000 lb, that is the difference between a reading you can certify and one you can only defend.

Built for SCAP, not adapted to it

Points are resampled onto uniform intervals — linear, cubic spline, Akima or logarithmic, whichever the curve calls for — and written straight into SCAP form. Each curve keeps its own extent, so a figure where the heavy weights are not certified at high altitude is stored exactly as certified, with nothing extrapolated the AFM never said.

Every value carries its source. Each figure records the axes it was read from and the reading tolerance it was taken at, and every reference value carries where it came from and when it was checked. This is a performance tool: invented data is worse than no data, and the software is built so that nothing can be entered without saying where it came from.

A worked example

A database that stopped 600 feet below its own AFM.

An operator's takeoff database refused every calculation above 8,400 ft pressure altitude with an environmental-envelope error. The AFM for that aircraft permits 9,000 ft. The airports in question sat in between.

  • The obvious fix was wrong. Extending the altitude table to 9,000 ft changed nothing — proved by running the manufacturer's own analysis tool against the modified file.
  • The real gate was a hardcoded constant in the instruction block: a single store instruction setting the ceiling to 8,400, compared against pressure altitude a few instructions later. It was present in all three treatments. Nothing in the tables would ever have reached it.
  • Found by tracing, not by guessing — the manufacturer's analysis software was run in trace mode until it showed the engine receiving the altitude and rejecting it, and the constant was located by scanning the instruction block for it.
  • Corrected and revalidated: the constant raised in all three treatments and the altitude table extended so the envelope check itself had bounds to work with. Dry and standing-water cases then computed cleanly to 9,000 ft — verified against the manufacturer's tool, not against our own engine.
  • And the honest part: the slippery case still stops at 8,000 ft, because that limit is imposed by a different mechanism entirely. We did not touch it, and we said so.
Screenshotimg/shot-scap-editor.jpg
full-precision BDB editor

How we validate

Nothing ships on our word alone

Our own engine agreeing with our own database proves nothing. Every database we build is exercised across its whole envelope and checked back against the AFM it came from, figure by figure. A number we cannot demonstrate that way does not get delivered.

Have a database that will not do what you need?

Tell us the aircraft and the case it refuses. We will tell you whether it is a data limit, a coded limit, or genuinely the certified edge of the aeroplane.