All projects

The Bishop platform

Sulaco.

From rehearsal
to physical operation.

I build Bishop: the runtime, the simulation and the interfaces that connect a procedure to the equipment it controls.

Runtime engineering · Simulation · Product & interface design

sulaco.io

Follow an operation through Bishop.

The Bishop platform, from rehearsal to operation Studio authors procedures. BishopCX models and rehearses an operation with BishopRT. BishopOS provides operator controls. BishopRT executes to equipment. BishopIQ reads the operational record to provide insight. Studio Author the procedure BishopOS See, authorise, operate BishopCX The modelled operation The physical site Equipment & existing systems BishopRT ONE RUNTIME BishopIQ Read-only insight · Optional CAPABILITY OVERVIEW

BishopCX

Begin with
the operation.

Start with the equipment, connections and conditions that a procedure depends on. BishopCX models that part of the site so the team has somewhere to rehearse.

A model of the operation comes first.

Studio

Write the
intended response.

Studio is where procedures, automations and productions are authored. It describes the intended actions and conditions, ready to be checked and rehearsed.

Studio authors. BishopRT executes.

BishopCX + BishopRT

Rehearse before
authorising.

Run the procedure against the model, including degraded and failure conditions. BishopRT is the execution layer used for rehearsal and for the accepted operation on site.

The rehearsal and the site share a runtime.

BishopOS + BishopRT

Take the accepted
procedure to site.

Once the agreed checks and approvals are met, the procedure can move to site operation. BishopOS gives people the controls and visibility. BishopRT executes to the equipment.

People authorise. The runtime acts.

BishopOS + BishopIQ

Keep the operation
in view.

Operators follow the site and its record through BishopOS. Optional BishopIQ adds prediction, anomaly detection and questions about the operation, with read-only access.

Insight informs the work. It has no execution authority.

Illustrated capability overviewFive steps · About 30 seconds

What I build

The whole path,
with distinct jobs.

The work spans systems engineering and product design: connecting equipment, modelling its behaviour, writing the authoring tools and shaping what an operator sees.

Execute

BishopRT

The deterministic runtime. Device integration, authoritative operational state and execution of accepted procedures all meet here.

Model & rehearse

BishopCX

The commissioning environment. Facility models, simulated equipment and rehearsal workflows give a team a way to examine a change before accepting it for the site.

Author

Studio

The visual authoring surface shared by BishopOS and BishopCX. Procedures, automations and productions are defined here for BishopRT to execute.

Operate

BishopOS

The browser interface. The command centre, topology, maintenance and operational views bring the runtime’s state into a workspace people can use.

Around the execution layer

Intelligence.
A home on site.

Bishop also spans the software and hardware around that workflow, from an operator’s questions to the equipment in the field.

Insight

BishopIQ

Optional prediction and anomaly detection. It reads the operation and helps people understand it.

Site hardware

MUTHR

The site box: a home for the runtime, the operational model and record, and the interface served to operator browsers.

Field hardware

Bishop Edge

Controlled field hardware that connects the platform to sensing and actuation at the equipment.

Explore the Bishop platform

Systems engineering / Built at Sulaco

From kernel
to console.

My work on Bishop went through the application, into the runtime and down to the host. This is engineering I built at Sulaco, a separate company I founded.

A custom runtime and instruction set.
A deterministic Rust runtime, a compiler and instruction set, device protocol integration, telemetry processing and simulation. The operator interface was one part of that system.
Code inside the Linux kernel.
Custom eBPF programs for packet validation and command control, using XDP and traffic-control hooks. The host work also included real-time Linux configuration and isolated CPU cores.
The infrastructure around it.
Time-series data storage, authenticated messaging, service orchestration and centralised logs. The work extended to dedicated physical servers and the private networking between them.

More of the work

Studio