Platform

A field terminal, a shipboard computer and an engineering workstation make different demands on the operating system.

The equipment, the load, the ways of control and the availability of a link differ. So do the consequences of a failure and the time in which work has to be restored.

We develop RUS OS as a foundation for building systems for a concrete purpose. The set of components, the settings and the order of maintenance have to match the conditions in which the device will work.

Design starts with understanding the task.

Who uses the device? What equipment is connected to it? Which functions have to stay available all the time? How many resources may be used, and what happens on failure?

For an industrial complex, interaction with equipment and predictable behavior matter. For a portable terminal, limits of power and autonomous work are added. A workstation needs performance and professional tools.

These requirements determine how the system is built and the criteria by which it is checked.

Every component needs resources, configuration, updates and support.

We keep to a justified set: include in the system what is necessary for its purpose, its operation and its recovery.

A device with a fixed function can do with a small set of services. A specialist's workplace needs a wider software environment. Means of diagnosis and maintenance are needed in both cases, but access to them is arranged for the user's role.

The makeup of the system has to be known, fixed and reproducible.

Support for a device is made of many details: boot, drivers, power, storage, peripherals and behavior on failures.

A suitable processor architecture by itself does not mean the whole configuration is ready for operation.

So we look at the equipment together with the software environment. For each target configuration the working modes, the limits, the set of connected devices and the order of trials have to be defined.

The result has to be a checked configuration with clear boundaries of support.

Performance matters in a concrete case.

The system may have to process a stream of measurements, show a map, record data or run a calculation. Several tasks can compete for the processor, memory, storage and the communication channel.

Design has to set priorities, acceptable delays and behavior when resources run short. An auxiliary operation must not push out the main work of the device without control.

If a task requires a response time, that requirement has to be measurable and checked on the target equipment.

Every service and application has to have defined authority and dependencies.

Access to equipment, data and network connections is given according to the purpose of the component. Interaction between parts of the system has to pass through the interfaces that were provided.

This approach helps limit the consequences of errors, simplify diagnosis and change individual components with control over the effect on the rest of the system.

The mechanisms of isolation are chosen for the equipment, the load and the security requirements.

Loss of power, a full drive, an unavailable sensor and a broken link have to be taken into account in design.

For each significant failure the behavior of the system has to be defined: which functions keep working, which stop and what is required of the operator.

Recovery has to account for the integrity of data, the state of the equipment and whether an operation may be run again.

It is especially important to define a safe state in advance. For different devices it will differ, and it has to agree with the purpose of the whole complex.

A working system has a concrete version and a known makeup.

Changes require accounting for dependencies, a compatibility check and trials. It has to be clear which source components produced the build, which settings were applied and which equipment it is for.

We treat a reproducible build, version control and traceability of changes as the basis of supporting the platform.

An update has to follow the established path from development to the target device.

The platform needs tools with which an engineer can build an image, connect equipment and check the result.

This direction includes preparing configurations, building components, debugging, logging and automating trials.

Documentation has to describe interfaces, dependencies and limits. An integrator needs to understand what they can change on their own and which changes require the system to be checked again.

This creates a basis for developing a family of devices and for bringing in new participants in development.

Readiness is determined by the results of trials.

Booting and starting the application is the beginning of the check. Then come the working load, long operation, limited resources, loss of the link, a sudden power cut and recovery.

For each configuration the conditions of the trials, the results and the known limits have to be recorded. The statuses of research, prototype and supported solution have to be kept plainly separate.

A device can stay in operation for many years. In that time components change, new requirements appear and practical experience accumulates.

The architecture of the platform has to account for diagnosis, maintenance, replacement of equipment and development of the software environment.

We build the approach to RUS OS around this responsibility: to understand the makeup of the system, to check its behavior and to keep the ability to manage it for the whole service life.

So that an engineer can justify a decision, a specialist can maintain it, and an operator can do their work.