Non-standard tasks

The site is far from infrastructure. The equipment has to work for years. The link comes up on a schedule, power is limited, and a ready-made device does not fit in size or in the way it is controlled.

Sometimes the task needs its own system configuration. Sometimes it needs a different interface, a new module or the development of a whole complex.

We look at such projects where hardware, operating systems, communications and security meet. We start from the working conditions and the result that has to be achieved.

Standard equipment is designed for certain scenarios. A real task can go beyond them.

A non-standard instrument has to be connected, compatibility with an existing complex has to be kept, or a computing system has to fit into a limited space. Autonomous operation has to be provided, control has to change, or data has to go over the radio channel that is available.

In such projects it is important to determine which parts can be used without changes, what will have to be adapted and where our own development is required.

The purpose determines the design.

For a portable terminal, weight, power and control on the move matter. For an onboard computer, the connection to equipment, placement and maintenance. For a remote node, power consumption, autonomy and recovery after a failure.

We look at the device as a whole: the computing part, interfaces, communications, the software environment and the requirements for its physical design.

Decisions on each component have to take the work of the whole complex into account.

A site may already have instruments, controllers and software systems in operation that have to be kept.

Such a project starts with a study of the interfaces, data formats, the available documentation and the actual behavior of the equipment.

Then the ways of connecting, converting data and checking compatibility are defined. Separate attention goes to the limits of the existing complex and to whether trials can be run without disrupting its work.

The transition plan has to account for commissioning, checking the result and the order of returning to the previous configuration.

A remote device has to do its job within the resources available.

The data to keep locally, the priorities of transfer and the allowed length of work without outside services are defined in advance. Energy use, storage capacity and the possibility of maintenance on site are taken into account.

If the channel is available only at times, the exchange has to account for delays and for how current the information is. If power is interrupted, a considered order of saving state and starting up is required.

Autonomy has to be expressed in concrete modes and in conditions that can be checked.

A specialized task may need its own interface.

The operator needs specific readings, commands and sequences of actions. The way of control depends on the workplace: a touch screen, physical buttons, a keyboard or external controls.

We look at the interface together with the equipment and the working procedures. Which actions are done most often? Where is an error likely? What has to stay available if part of the system fails?

The answers shape the requirements for the workplace.

A custom project can rely on solutions already proven in other devices.

Shared computing, communication and software modules help reduce the amount of new development and simplify diagnosis and maintenance.

Compatibility has to be defined in advance: electrical and software interfaces, power, mounting, thermal conditions and conditions of use.

For replaceable modules it is important to set the order of replacement and of the check that follows. A specialist has to understand which component fits, which settings have to be kept and how to confirm that the device is ready for work.

This is how a family of solutions takes shape, with shared spare parts, tools and maintenance procedures.

Not every requirement can be confirmed by calculation or documentation.

Critical assumptions have to be checked early: the availability of a radio channel, the compatibility of an instrument, the performance of a computing module or the energy use.

For this we plan prototyping and separate trials of the most uncertain parts of the project.

The result of this stage is confirmed capabilities, identified limits and grounds for further decisions.

Work on a test bench has to be compared with real operation.

The working load, the connected equipment, the quality of the link, power and the operator's actions are all checked. For harsh conditions, the requirements for external influences and the ways to confirm them are defined separately.

Trials have to cover failures: a lost connection, an unavailable sensor, a full drive and a sudden power cut.

Acceptance criteria are agreed in advance. It has to be clear which result is considered sufficient and which limits remain.

After installation the device will need diagnosis, updates and repair.

So already during design, the available means of maintenance, the set of documentation, spare modules and the order of recovery have to be defined.

The life cycle of components is taken into account as well: availability of supply, possible replacements and the need for repeated trials when the configuration changes.

The solution has to stay maintainable in the conditions it is built for.

For a first conversation it is enough to describe:

• What the complex has to do and who will use it.
• Where and in what conditions it will work.
• What equipment is already in place.
• What power and communications are available.
• What limits the size, the time and the cost.
• How maintenance is planned.

If some of the requirements are not defined yet, we will start by clarifying them.

Our task is to turn the initial need into clear technical requirements, check the key decisions and define the path to a working complex.

RUS OS channel on Telegram