Skip to main content
project@netbasejsc.com
Mon–Sat: 9:00–18:15, Sun: closed
91 Nguyen Chi Thanh, Hanoi
Facebook X (Twitter) LinkedIn YouTube

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Robotics software: assess the interface boundary before a proposal

A robotics software feasibility assessment produces four things: interface contracts for every message the software reads or proposes, recorded fixtures that replay real traffic in simulation, a traceability record linking each decision to its source data, and a go or no-go recommendation. Physical safety stays with a qualified safety reviewer from the first meeting.

Submit a project Assess a workflow first

Reviewed by Huy Nguyen (David), CEO · Updated 6 Oct 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, which scopes and builds integration software, so we have an interest in your decision. The method applies whoever builds yours. This guide is for CTOs, operations leaders and product owners connecting business systems to robots, automated guided vehicles, robotic cells or fleets, where the software side is the question and the machinery already exists or is supplied by others.

What this guide covers

Which part of the problem is software?

Most robotics projects that reach an outsourcing supplier are integration problems rather than motion problems. A warehouse wants its order system to hand tasks to a mobile robot fleet and see what happened. A plant wants a dashboard that reconciles what a robotic cell reports with what the production system expected. A research team wants telemetry recorded, replayed and analysed.

Write the objective as an interface question: observe telemetry, reconcile an event stream, simulate a workflow, or prepare a task proposal for an authorised operator. Name the source systems, message types, permitted inputs and outputs, identity boundary, error states and owner for each interface. Then separate two kinds of message. Telemetry describes what a machine reports. A command asks a machine to do something and may have a physical consequence. The first scope should read telemetry and, at most, propose commands to a person who approves them through the machine supplier's own controls.

What does an interface contract contain?

Contract element Buyer question Acceptance evidence
Publisher identity Which node or system may publish this message? Named identity, credentials and permitted topic
Consumer identity Which service may read, transform or display it? Role map and a denied-access test
Schema and version What fields exist, and what happens when the schema changes? Versioned message definition and a compatibility rule
Timing and order What do stale, duplicate or out-of-order messages mean? Timestamps, sequence rule, correlation ID and exception queue
Delivery guarantees May messages be dropped, and does a late subscriber get the last value? Stated reliability and durability settings, tested
Authority Is this telemetry, a proposal or an approved instruction? Explicit state and the human approval boundary
Failure What happens when data is missing, delayed or malformed? Safe display state, owner and recovery route

In ROS 2 systems these elements map onto concrete settings. Messages travel on named topics with typed definitions; each publisher and subscriber declares quality-of-service settings such as reliability and durability, and mismatched settings can silently stop communication. The ROS 2 security enclaves design groups nodes into security contexts, each with its own identity and permissions over which topics it may publish or subscribe. A feasibility assessment should list the enclaves it needs and test that a node outside them is refused.

How do you build simulation fixtures?

  1. Record real traffic

    Capture authorised message logs from the running system, with their source, date, configuration and the operator's account of what happened.

  2. Replay against the software

    Feed recordings into the proposed service in simulation, on simulated time, and compare its interpretation with what operators say actually occurred.

  3. Inject faults

    Add stale, duplicate, reordered, missing and malformed messages. The software must expose uncertainty rather than invent a current state.

  4. Test revoked permissions

    Show a denied publisher, a denied consumer and an expired credential, with no silent widening of access or unsafe retry.

  5. Check traceability

    A reviewer should find the source message, configuration version, interpretation, exception and decision for any output.

  6. Decide with owners

    The operational owner, technical owner, security owner and qualified safety reviewer each accept the next step or record why it stops.

Diagram of a simulation test flow: recorded real traffic is replayed on simulated time, a stale message is injected, the software must expose uncertainty, and owners check traceability to the source message before the next step
Diagram of a simulation test flow

A worked example: reconciling a robot fleet with the warehouse system

A distribution centre runs mobile robots from a supplier's fleet manager. The warehouse management system assigns picks; the fleet manager reports task states. Operators say some picks show "complete" in one system and "in progress" in the other.

The assessment records a week of fleet-manager task events and warehouse updates, with permission from both system owners. Replayed in simulation, the reconciliation service matches events on task ID and timestamp. Three patterns appear: duplicate "complete" events after a network blip, a late "cancelled" event arriving after "complete", and tasks reassigned between robots under a new ID with no link to the original.

Each pattern gets a rule and an owner. Duplicates are ignored by sequence number. A cancellation after completion goes to the shift supervisor's exception queue, because only a person can say which is true. Reassigned tasks need a correlation field that the fleet supplier must add, so the assessment names that as a dependency and a blocker. No command is ever sent to a robot. The recommendation is to build the read-only reconciliation service now and revisit task handoff once the supplier confirms the correlation field.

What has Netbase delivered near this area?

Where a model is involved, Netbase works with commercial and open-source AI models chosen per project. Netbase applies the ISO/IEC 42001 AI management system framework to its own AI delivery practice, which shapes its own project governance and never substitutes for safety review of a machine.

Which questions should you ask a supplier?

  • What will the software read, and what may it propose?

    A message list split into telemetry and proposals, with no direct commands in the first scope

  • How will you test without the real machines?

    Recorded traffic replayed on simulated time, plus injected faults

  • How are node identities and permissions set?

    Named security contexts, per-node credentials and a denied-access test

  • What happens when message settings do not match?

    Documented reliability and durability settings, checked at startup

  • How are schema changes handled?

    Versioned message definitions and a compatibility rule agreed with the machine supplier

  • Who reviews physical safety?

    An independent qualified reviewer, named before scope grows

  • What do you need from the machine supplier?

    A list of interfaces, logs and contacts, with blockers named

  • What does the traceability record contain?

    Source message, configuration version, interpretation, exception and decision

What failure modes should you watch for?

  • Stale state shown as current

    Early signal
    Dashboard values stop changing while machines move
    Who acts
    Technical owner adds staleness indicators

  • Silent communication loss from mismatched settings

    Early signal
    A subscriber receives nothing with no error
    Who acts
    Technical owner checks settings at startup

  • Schema change after a supplier update

    Early signal
    Parsing errors or missing fields
    Who acts
    Operational owner requires version notice from the supplier

  • Scope creep from observe to command

    Early signal
    A request to "just send the task"
    Who acts
    Safety reviewer and security owner block until reviewed

  • Unowned exceptions

    Early signal
    Exception queue grows without action
    Who acts
    Operational owner assigns a reviewer

  • Fixtures that do not reflect reality

    Early signal
    Simulation passes, operators disagree
    Who acts
    Operational owner supplies new recordings

Plan the next step for your project

Submit a project Assess a workflow first

Common questions

The first scope should not. Keep it to reading telemetry, simulation and proposals that a person approves through the machine supplier's own controls. Any direct command path is a later decision that needs the machine supplier, a qualified safety reviewer and the security owner to agree the boundary first.

Mostly not. Recorded traffic from the running system, replayed in simulation, covers most interface questions. You need access to logs, message definitions and someone who can explain what operators saw. Occasional supervised checks against live read-only feeds help confirm the recordings are representative.

ROS 2 security enclaves frame software identity and permissions: which node may talk to which topic. Physical safety concerns what a machine does in its environment and needs separate, qualified review under the standards that apply to your equipment and site.

Yes. The same contract questions apply to a vendor API or message bus: identity, schema, timing, delivery guarantees, authority and failure. The machine supplier's documentation and cooperation become the main dependency, so name the contact early.

A recorded decision naming what blocked feasibility, such as missing correlation IDs, logs that cannot be shared or no safety reviewer available, and what would change it. That record is useful: it tells you what to ask the machine supplier for before spending on a build.

How this guide is sourced

Statements about Netbase map to approved claims backed by attested company facts listed under Sources, in their registered wording. External guidance comes from the ROS 2 security enclaves design article, dated below. The warehouse example is illustrative and describes no client. The cloud ERP record above shows messaging and integration work in business software; robotics interface software is offered through a scoped assessment. This page makes no judgement about physical safety, which needs a qualified reviewer. See the methodology for how claims are reviewed.

Bring the interface inventory

A first conversation goes furthest with a list of the systems involved, sample message logs, the machine supplier's interface documents and the question operators most want answered. Submit a project with those, or read the emerging technology adoption guide, the speech interface guide, the manufacturing and field service page and the other guides first; an AI Workflow Blueprint is the assessment route when the scope is still open. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

AI workflow blueprint: decide where automation belongs before you build AI workflow blueprint: decide where automation belongs before you build

A paid two-to-four-week project that ends in a scope you can approve, change or stop.

Learn More
line

Sources

91 Nguyen Chi Thanh, Hanoi

+84 937 869 689

Tell us what you want to build or automate.

Submit a project