Plavata Systems

Designed and executed in-house

The confirmed position is a strong one: flight systems are not specified and bought, they are designed and executed within the company. Design is deciding what the system will be; execution is making it exist and proving it works. Keeping both inside one organisation means the people who drew it are still reachable when it is being built, and still accountable when it is being tested.

That matters most at the joins. Most difficulty in a flight system is not inside the airframe, the avionics or the payload — it is in the assumptions each one makes about the others. Structure assumes what the electronics weigh and where they sit; electronics assume what the structure does under load; a payload assumes both. When those three sit in different companies, the assumptions are negotiated through contracts. When they sit in one, they are resolved by engineers in the same building.

Capabilities

The three sections below describe what each engineering domain involves.

Airframe

The structure and the shape: the load paths that carry flight and landing loads into the airframe and back out again, the aerodynamic surfaces that generate and control lift, the mass and balance that determine whether the whole thing is stable, and the mechanical provision for everything the aircraft has to carry. Airframe work is where weight is won or lost, and weight is the currency every other subsystem spends.

Avionics

The systems that sense, decide and act: sensing attitude, position and the state of the aircraft; control laws that turn that into commanded surface and power outputs; the links that carry data to and from the ground; and the electrical architecture that powers it, including what happens when part of it stops. Avionics is also where software lives, which means much of the discipline is verification rather than design.

Satellite systems

Engineering for an environment with no air, extreme thermal swings, radiation, and no possibility of maintenance after launch. Everything is downstream of that: power generation and storage across an orbit, thermal control by radiation alone, attitude determination and control, communications on a link budget that does not forgive, and structures that must survive launch before doing anything useful. The defining constraint is that the design has to be right the first time.

The shape of the process

Any organisation designing and executing flight systems needs a route from requirement to flight that is walked deliberately rather than improvised. The diagram below is the generic shape of such a process, not a description of Plavata’s own.

Requirements decompose downward: what the system must do becomes what each subsystem must do, becomes what each component must do. Realisation happens at the bottom, where things are actually built. Verification then climbs back up, and the discipline of the shape is that each stage on the way up answers the stage opposite it on the way down — the component is tested against its component specification, the subsystem against its subsystem specification, the system against the requirement that started it. Nothing is declared finished because it seems to work; it is declared finished because it satisfies the thing that asked for it.

The gates between stages are where a design is allowed to proceed, or is not. What makes a process real is not that the gates are drawn, but that the organisation is willing to hold something at one.