Schema-Driven System Configuration

A configuration file is usually treated as a list of settings. The one I help define and validate is closer to a model of the system itself: which devices and loads are connected, how inputs and outputs are assigned, and how the controls, the interface, and the network are supposed to behave. The difference is that a model can be checked against itself. A schema, in the formal sense, says what a valid configuration is allowed to contain. For a vehicle that means rules like: every load is attached to an output that exists on a device that exists, no output carries two loads, a dimmer is only assigned to a channel that can dim, every instance number is unique among devices of its kind, and every relationship points at something real. Validation against those rules turns a whole class of installation mistakes into error messages that appear before anything is powered. When the model is right, a deployment is a description of the real installation. When it is wrong, it is a description of something that doesn’t exist, and the validator is the only thing standing between that description and a live vehicle.

My part of the work is translation in both directions. Embedded-system constraints become software requirements: a controller with four channels cannot be given a fifth load, a channel rated for a few amps cannot be handed a heater, and a network with a fixed set of instances cannot have one instance meaning two things. Physical relationships become schema definitions: this switch controls that light, this tank sensor feeds that gauge, this input disables that output while it is active. Then I check the results. The model is only useful once it compiles into the files the devices actually run, so I confirm that generated deployment files still describe the intended system rather than an earlier version of it, reproduce configuration and export failures so they can be fixed rather than worked around, test deployments on physical hardware, and help installers and developers check that the configuration matches the wiring and the intended behavior.

Once a configuration controls real hardware, it stops being a collection of settings. A stale schema, an invalid assignment, a missing relationship, or a failed export can change how the deployed system behaves, and the failure doesn’t announce itself as a configuration problem. It looks like a light that won’t turn off, a pump that runs with no one asking, an interface showing a tank that isn’t there. At that point a mistake in a file is a physical system fault, and the schema exists so that it gets caught as a file problem first.