Baptisia

Safety rules as program structure

Baptisia is a small domain-specific language (DSL) for industrial-control experiments. Its premise is simple: safety-critical control code should not rely only on an engineer remembering the right order of operations. If a watchdog, input validation, safety checks, or a failsafe path are structurally required, the compiler can make certain unsafe shapes impossible to emit.

A Baptisia device definition describes inputs, outputs, safety conditions, a failsafe, and control logic. The generated control loop follows a fixed order: boot, read inputs, validate ranges, run safety checks, run control logic, then write outputs. A safety violation calls the failsafe and returns before ordinary control logic runs in that cycle.

That makes the project interesting as a language-design experiment. It does not claim that a language alone makes an industrial system safe; it asks which useful guardrails can be represented directly in the source language and enforced before C is ever produced.

From .ba source to a simulated controller

.ba → lexer/parser → abstract syntax tree → semantic analysis → C → hardware abstraction layer/simulation

The Go compiler tokenizes and parses a .ba program into an abstract syntax tree (AST), checks declarations and required control blocks, then emits C. Semantic analysis rejects undefined identifiers and validates the structural pieces. Code generation places watchdog reset, input validation, the safety block, failsafe return, and ordinary control section in the prescribed shape instead of trusting every program author to recreate it correctly.

Baptisia also includes a hardware abstraction layer (HAL) and small physics simulation. A generated C control loop can run against modeled pump behavior, where pressure, flow, temperature, and a latched fault feed back into later cycles. That makes the compiler path inspectable: a threshold can trip, the failsafe runs, and the failsafe returns before ordinary control logic runs in that cycle.

Trying the language shape

The repository includes example motor and pump programs. This shortened pump fragment shows the required separation between safety, failsafe, and control; the full example also declares inputs, outputs, constants, and states.

device pump : SCADA {
    watchdog: 500ms
    cycle: 100ms

    safety {
        if psi >= max_psi OR flow >= max_flow : state = FAULT
    }
    failsafe {
        state = FAULT
        output(motor_relay, off)
    }
    control {
        if psi < max_psi AND flow < max_flow : state = RUNNING
        else : state = IDLE
    }
}

With Go and a C compiler installed, a normal compile emits C; simulation mode leaves out a standalone main so the generated control loop can link against the included HAL and physics engine.

go run main.go motor.ba
go run main.go -sim "test files/OR_logic.ba"

What the compiler can enforce—and what it cannot

These are guarantees about the compiler's output shape. A program can obey a safe ordering and still encode a bad engineering assumption. Moving certain rules into the language is interesting because it removes some control-flow mistakes from the set a program can express; it does not validate the physical system around that program.

The simulation demonstrates a model, not a plant. It is not industrial safety validation, a certified toolchain, or a substitute for hazard analysis, testing, review, and the standards that apply to a deployed control system. Baptisia remains R&D into making particular structural mistakes harder to write.

Sources and further reading

Baptisia README (commit 8de63a7) · Language reference (commit 8de63a7)