Skip to content
CMSIndustry 4.Now
EN
PortuguêsPT EnglishEN EspañolES
Free trial Book a demo

Industry 4.Now

The integration hub of a connected plant.

Your MES was built to run production, not to keep dozens of connections alive and overloaded. CMS takes over the integrations, the security and the monitoring — and scales, giving you end-to-end visibility of every integration.

Book a demo See the architecture

The only industrial integrator with AI: describe the field mapping in plain language and CMS builds the transformer between applications, simply and quickly.

OPC UA SAP RFC / IDoc MQTT REST / JSON ERP SAP / TOTVS External applications REST / SOAP / files Databases SQL / historians Quality LIMS / inspection Maintenance Work orders / assets Logistics WMS / shipping Supply chain Scheduling Sensors IoT / scales Shop floor PLC / OPC UA CMS · INTEGRATION AND CONTROL COLLECT · RECEIVE · TRANSFORM · DELIVER · MONITOR MOM / MES Production operations CMS central monitoring InterfacesReal time Audit trailTraceability AvailabilityMonitored
Drag to see the full diagram
SAP RFC / BAPISAP IDocOPC UAModbus TCPMQTTSQL ServerOraclePostgreSQLSQLiteInfluxDBMongoDBRESTSOAPPI Web APISparkplug BLoRaWANArquivos

Platform

CMS – Collaborative Manufacturing SuiteIndustry 4.Now

When there is no integration layer, factory data ends up scattered, integrations become hard to trace and the knowledge remains tied to individuals. The result is an operation that is more dependent, less transparent and more exposed to risk.

Application dashboard: every integrated system, with current state and availability.
Application dashboard: every integrated system, with current state and availability.
Integration Map Who talks to whom: every system and its integrations in one diagram, with the volume exchanged and the system that went down blinking.
Integration Map Who talks to whom: every system and its integrations in one diagram, with the volume exchanged and the system that went down blinking.
Cockpit Wallboard for the shop-floor TV: what is up and what went down, with the panel registered in the system and nobody logged in.
Cockpit Wallboard for the shop-floor TV: what is up and what went down, with the panel registered in the system and nobody logged in.

We built CMS – Collaborative Manufacturing Suite, a platform designed to centralise, control and monitor the integrations between shop-floor systems and corporate systems, covering both the SAP and non-SAP ecosystems.

CMS was conceived to support the main integration needs of an industrial operation, connecting machines, equipment, factory applications, MES systems, ERPs and other corporate platforms.

The five stages

How CMS operates

Every flow goes through the same five stages. That is what turns a new integration into configuration instead of a software project.

  1. Receive

    A ready REST endpoint for each definition and a SOAP web service with a dynamically generated WSDL. Authentication by application API Token or WS-Security.

    • REST
    • SOAP + WSDL
    • API Token
    • Sync or async

  2. Collect

    When data does not come to you, CMS goes after it: SQL query, BAPI call, MQTT topic, an OPC UA tag that changed, a Modbus register, an HTTP endpoint. On a schedule or on an event.

    • Scheduled pull
    • Event push
    • Multiple forwarding
  3. CMS exclusive

    Transform

    Given the source and destination payloads, you can use an AI prompt to map the fields in plain language and let CMS build a transformer to be used in your collection and delivery definitions.

    • AI field mapping
    • Plain language
    • Reusable

  4. Deliver

    Asynchronous or synchronous interface with sequential or parallel ordering, plus timeout, retries and backoff per definition. The destination can be an ERP, a database, an MQTT broker — or a PLC tag.

    • Guaranteed order
    • Automatic retry
    • Bulk reprocessing

  5. Monitor

    Application availability by keep-alive, blocked interfaces, message backlog, technical and business errors — with alerts by e-mail, WhatsApp and on-screen notification.

    • Uptime per application
    • TV wallboard
    • Alerts per event

Many plants live with them thinking it is normal. Tick the ones that happen at yours.

Tick the signs that happen at your plant.

The same scenario without an integration layer: each system talks straight to the other. It works on the day everything is up — the problems show up on the other days.

  1. 01

    The LIMS goes down and the order sent by the ERP is lost. Storing and resending becomes the producer’s job — and each system does it its own way, if at all.

  2. 02

    The ERP fires 2,000 messages at once and the MES cannot cope. With no queue in between, nobody holds the volume and delivers at the target’s pace.

  3. 03

    Nobody is notified. The failure shows up when production notices, and every team says everything is fine on its side.

  4. 04

    Each link has its own format translation, scattered across systems. Replacing the MES means touching every integration that talks to it.

  5. 05

    Each system has its own log, on a different screen. Finding one message means opening five consoles — and nobody sees the integration end to end.

Plant 1000 without CMS IDoc→JSON IDoc→XML IDoc→OPC SQL→JSON OPC→SQL ERP Production order Database Collection · SQL MES Production · JSON LIMS Laboratory · XML PLC Shop floor · OPC UA IDoc ✕ Message lost Who resends? 2,000 messages at once MES down Silent failure: nobody was notified The PLC never sent it Everything is fine on my side 5 conversions in 5 different places logloglogloglog 5 separate logs, no end-to-end view
Click a problem to see it. Right below, the same scenario with CMS.
Without CMSWith CMS
Connection drops and the message is lost; resending falls on the producerThe Interface blocks, holds the message and delivers when the connection is back
A peak of messages takes the target downThe queue absorbs the peak and delivers at the target’s pace
The failure shows up when production noticesThe alert opens a help desk ticket and notifies a phone
One format conversion per pair of systemsThe Transformer lives in one place, reused across integrations
No history: no way to prove what was sent or to reprocessHistory per message, with single or bulk reprocessing
Messages out of order: the confirmation arrives before the released orderSequential Interface: each message waits for the previous one
Each system with its own log; nobody sees the whole integrationOne panel with every integration, message by message

From intake to destination confirmation, every step is persisted. When something fails, the difference between a technical problem and a data problem is already classified.

  1. 01

    Intake or collection

    The message arrives over REST, SOAP or an active collection, and is stored before any processing.

  2. 02

    Interface queue

    It becomes a job in the interface. A blocked interface holds the message instead of failing against a destination that is down.

  3. 03

    Transformation

    If the definition has a transformer, the payload is converted to the destination format.

  4. 04

    Delivery

    Sent with its own timeout. A technical failure goes back into retry, with a wait between attempts.

  5. 05

    Classification

    Every message ends in an outcome, stored in its history, that says where it stopped.

    • Processed
    • Collection Error
    • Transformer Error
    • Delivery Error
    • Business Error
  6. 06

    Reprocessing and retention

    Errors are resent one by one or in bulk, always as a new attempt. Retention purges old history.

Plant 1000 with CMS CMS Intake Interface Transformation Delivery Receives · Collects PLC response written back to the database Delivery Collection Delivery ERP Production order Database Collection · SQL MES Production · JSON LIMS Laboratory · XML PLC Shop floor · OPC UA Processed Connection lost Connection restored Processed Processed Interface blocked Alert: LIMS connection lost Ticket opened in the help desk Notice sent to the phone IDoc 1001 { } JSON IDoc 1001 </> XML IDoc 1002 </> XML IDoc 1001 0101 BIN SQL { } JSON Reply Reply
One ERP order goes to the MES (JSON), the laboratory (XML) and the PLC (OPC UA), and a reading collected from the database is also delivered to the MES, on its own line. The connection to the laboratory drops: its Interface is blocked and holds the message — and the next order waits behind it. The alert opens a ticket in the help desk and notifies a phone. When the connection is back, both are delivered, in order. The PLC response comes back through CMS and is written to the database. Click a step to see it. The payload can be JSON, XML, CSV, text or binary: CMS carries each system’s own format.

Architecture

Get the integration intelligence and visibility you need to run your plant across many systems efficiently.

Pick the scenario and follow every step of the data. CMS connects enterprise and industrial systems, whatever the protocol, making sure data is received, processed and delivered with every integration fully monitored.

SAP DM SAP S/4HANA TOTVS(Protheus / Datasul) SAP PI/CPI MES Systems Plant Historians Laboratory Systems External App CMS – Collaborative Manufacturing Suite On-Premise / Cloud AWS On-Premise / Cloud AWS SCADA / HMI Services DCS Systems MES Systems Custom Database Plant Historians SPEC/SQC Systems Laboratory Systems Maintenance Systems SCADA / HMI Services DCS Systems Custom Database SPEC/SQC Systems Maintenance Systems
Drag to see the full diagram

Integrations

Connects ERP, MES, the shop floor and everything in between

Pick a category to see what CMS talks to, how and in which direction. Collection is data coming into CMS; Delivery is data going out.

  • SAP
  • TOTVS
  • SAP DM
  • AVEVA MES
  • DELMIA Apriso
  • Rockwell FactoryTalk
  • Oracle
  • SQL Server
  • PostgreSQL
  • TimescaleDB
  • MongoDB
  • InfluxDB
  • AVEVA PI
  • OPC UA
  • MQTT
  • Sparkplug B
  • Modbus
  • SAP Integration Suite
  • OData
  • ServiceNow
  • ISA-95
See what each protocol does on Collection and Delivery
TechnologyInbound (Collection)Outbound (Delivery)
HTTP RESTQueries to APIs and inbound callsSending, updating and deleting records
SOAPService published by CMS for the other system to callCalls to the vendor web services
MQTTSubscription to broker topicsPublishing to topics
SQL ServerReading tables and views, marking what has been readWriting records and running procedures
OracleReading tables and views, marking what has been readWriting records and running procedures
PostgreSQL (includes TimescaleDB)Reading tables, views and time seriesWriting records and running procedures
SQLite (file-based database)Reading tables and viewsWriting records
InfluxDB (1.8, 2.x and 3.x)Time series queries and aggregationsWriting measurement points
MongoDBReading collections, only what changed since the last runWriting documents
MongoDB AtlasReading cloud collections over an encrypted connectionWriting documents
Azure Cosmos DB (Mongo API) and AWS DocumentDBReading collections, through MongoDB compatibilityWriting documents
SAP RFC / BAPICalling SAP functions and BAPIsCalling SAP functions and BAPIs
SAP IDocReceiving IDocs of any typeSending to SAP through a function or BAPI
OPC UAReading tags and triggering on value changeWriting tags on the equipment
Modbus TCPCyclic register reads and triggering on changeWriting to registers
Sparkplug BSubscription to the devices published on the brokerSending commands to devices
LoRaWAN (through the Network Server)Sensor uplinks, from ChirpStack or The Things StackSending downlinks to the sensors
PI Web API (AVEVA/OSIsoft)Current value, history, interpolated and summaryWriting values back to PI
Files (directory)Watching a folder and reading the files that arriveGenerating files in a folder or share

Ticket opening

The alert arrives as a ticket in your help desk

When an interface blocks, a connection drops or a message fails, CMS opens the ticket in the company’s support tool, with the application, interface and error already filled in — and notifies whoever is on call by e-mail or WhatsApp.

Each alert type can open a ticket by itself, with nobody copying the error from one screen to another.

On a failed message, one button opens the ticket with the failure context attached.

The integration with each help desk comes as a pack: just provide the connection and the credential.

Tools already mapped in CMS

SAP Manufacturing Packs

Your SAP PP, QM and PM integrations come ready

The expensive part of integrating with SAP is not the software: it is working out which BAPI to call, which fields it requires, in what order and how to read the return. The CMS ships with that knowledge packaged — you pick the scenario and the interfaces are created configured.

108ready scenarios across production, quality and maintenance
3SAP modules covered: PP, QM and PM
4wizard steps, with no code to write
100%of the functions verified against a real SAP

Time ticket or order confirmations, component goods issue, finished goods receipt, order release and technical completion, batches and order backlog reads.

Inspection lot backlog, characteristics to measure with nominal and tolerances, result recording, in-process inspection points, usage decision and quality notifications.

Create and close notifications, technician time confirmation, orders and assets — plus measurement recording straight from OPC UA, Modbus or PI.

From install to first message

  1. 01

    PP, QM or PM, on the application that talks to SAP.

  2. 02

    The essentials preset comes checked. Add the rest when you need it.

  3. 03

    Plant, storage location and movement types. Once, for every interface.

  4. 04

    You see exactly what will be created before anything is written.

AI-assisted configuration

Point at the API. CMS writes the integration.

The packs solve SAP, the system we already know from the inside. The assistant solves the rest of the estate: any API with Swagger, OData, WSDL or a Postman collection — and, when there is no documentation at all, the address plus a sentence saying what you need.

Integration Assistant: you give the API address and, when there is one, the contract — CMS discovers the operations and proposes the Interfaces, Collections and Deliveries.
Integration Assistant: you give the API address and, when there is one, the contract — CMS discovers the operations and proposes the Interfaces, Collections and Deliveries.

Swagger/OpenAPI in JSON or YAML, the OData $metadata of SAP Gateway, a SOAP WSDL or a Postman collection. CMS recognises it by content, not by extension, and looks through the conventional paths on its own when you give it only the base address.

With no documentation, CMS makes a fenced-in read of the URL — GET only, with limits on time, size and redirects — and uses the real response as its base. You add the intent in plain language: "I need to pull open orders and confirm production".

PostgreSQL, SQL Server, Oracle, SQLite, MongoDB and InfluxDB. The tables, the types and the key are already in there: reading and writing come out ready, with the SQL command in plain sight before anything is saved.

From URL to configured integration

  1. 01

    A URL, a contract or a database connection you already registered.

  2. 02

    Operations arrive grouped by business scenario, not as a raw list of endpoints.

  3. 03

    You see what will be created, rename whatever you want and can reuse existing interfaces.

  4. 04

    Everything is born disabled. Nothing starts running because the system decided so.

Included in CMS. The AI is optional and can run on your own infrastructure.

See the assistants documentation

AI Agent

The alert arrives already investigated.

A queue blocks at three in the morning. Today that becomes an e-mail with an error code and someone opening five screens to work out what happened. The agent walks that path before you do: it runs the tools of the CMS itself against your installation, looks at what actually came back, and hands over a report with the evidence behind every step.

The agent report: every step shows which tool ran, what it returned and how long it took.
The agent report: every step shows which tool ran, what it returned and how long it took.

"Why did the ORDERS interface stop?" — it chains interface status, recent errors, message search and the definition, and every line of the report shows what the tool returned. In this mode it only reads: the worst case is a poor answer, never damage.

Given a goal in plain language it probes the source, assembles the plan of Interfaces, Collections and Deliveries, and tests it before showing anything. Writing stays parked until someone approves it on the review screen, object by object.

Blocked queue, piled-up messages, application offline: the alert that fires becomes an investigation, and the report lands in the inbox of whoever receives that alert. It ships switched off — it is the one part of the product that would spend the AI key with nobody having clicked.

How the work happens

  1. 01

    One sentence. The scope is the application in focus in the header, not one more form to fill in.

  2. 02

    Every tool runs against your installation and the real result goes back into the reasoning. When a probe returns 401, it is the agent that fixes the path — before any screen opens.

  3. 03

    The timeline shows which tool ran, what came back and how long it took. There is no conclusion without the step that supports it.

  4. 04

    Writing happens on your click, in a review that lists object by object — and it is recorded so it can be undone.

Book a demo

Features

Product features

56 screens, grouped as in the product menu and subject to each user's access profile.

Monitoring

  • Applications PanelOnline/offline status of each system via keep-alive, with an audible alert when one drops
  • Interfaces PanelVolume, errors and blocks per application and interface, filtered by period
  • Messages MonitorReal-time view of the messages flowing through every interface

Analysis & Diagnostics

  • All MessagesSearch by status, application, interface and period, with a timeline of every attempt
  • Processed MessagesProof of delivery, with the response the destination returned
  • Content SearchSearches inside the payload, not just the metadata
  • Delivery ErrorsTechnical and business failures, reprocessed one by one or in bulk, with the reason recorded
  • Cancel MessageBulk discard, with confirmation and a mandatory reason

Integration

  • ApplicationsIntegrated systems, with code, connections and availability monitoring; deactivate them or stop them for maintenance without false alarms
  • InterfacesSequential or parallel order, blocking and release with history
  • Message DefinitionAll collections and deliveries of an application in one panel, created and edited without leaving the screen
  • Collection DefinitionsWhere the data comes from: protocol, input parameters, conditions and forwarding
  • Delivery DefinitionsDestination contract: protocol, timeout, retries and transformer
  • TriggersInternal schedule that runs collections and deliveries with fixed parameters
  • RoutersOne API that receives the payload and fans it out to several deliveries by decision rules
  • Business ErrorsRules that classify the destination response as a failure and block the interface
  • Application VariablesFixed, dynamic or calculated values scoped to one application
  • TransformersScripts reused across collections and deliveries, tested against real messages
  • Encryption RulesConditional encryption by wildcard text and flow direction
  • ITSM ConfigurationOpens a help desk ticket when an alert fires or straight from a failed message
  • MCP Server AppIntegrations exposed as MCP tools for AI assistants, with usage per credential
  • AlertsThirteen event types, filtered by application, interface and definition

Integration Lab

  • Test BenchFires a collection or delivery on demand and shows what went in and what came out
  • Test PlansSaved scenarios with the expected result, re-run after every change
  • SimulatorsBuilt-in OPC UA, Modbus TCP and PI Web API servers and a LoRaWAN broker, with profiles per simulated device

Reports

  • Daily ReportThe day in one page, linking to the screen where each problem is fixed
  • Integration MapWho talks to whom: applications and interfaces in one diagram
  • Application OfflineUptime and downtime per application, with an annotated timeline
  • Interfaces BlockingNumber of blocks and total blocked time in the period
  • Business ErrorsOccurrences grouped by application, interface and definition
  • Collection LogHistory of reads at the source
  • Shipping LogHistory of completed deliveries
  • StorageVolume and bytes along the application → interface → definition hierarchy
  • Scheduler LogPast runs, with duration and result
  • Audit LogSensitive actions with user, result, justification and IP
  • AI SessionsWhat the AI agent ran in each session, and the report it delivered

Transports

  • Build packagePackages interfaces and individual items from the test environment for production
  • Built packagesHistory of what was sent, to which environment and with what outcome
  • Received packagesApproval before applying, with rollback after activation
  • Environments and tokensTarget environments and the key that authorizes each shipment

Security Services

  • ProfilesPermission per screen and access level — drives the menu and what the API allows
  • UsersLocal or LDAP/Active Directory login, with allowed interfaces per user
  • API KeysOne token per application, with a history of who copied it and when
  • CredentialsBasic, bearer, token login and WS-Security, encrypted at rest
  • Encryption KeysAES-256-GCM with a list of who may decrypt
  • MCP Server CMSToken that lets an AI assistant operate CMS with a user's profile

Settings

  • ParametersBranding, language, SMTP, retention, 2FA, LDAP and AI features
  • Global VariablesValues reused in any configuration, set once for the whole installation
  • Stop ReasonsCatalog that separates planned stops from incidents in the availability report
  • Scheduled StopsOne-off or recurring maintenance windows, for one or several applications, with planned vs. actual
  • External ConnectionsHTTP, databases, SAP, PI, MQTT, OPC UA and Modbus, with a test and status for each connection
  • Wallboard and MonitoringShop-floor TV panel, with its own token and per-application scope, and a read API for Zabbix and similar tools
  • SchedulersCron or interval jobs, with enable, edit and manual run
  • WorkersActive, waiting and failed jobs, with bulk retry and reset
  • Danger ZoneDestructive operations and configuration import/export between environments
  • LicenseValidity and enabled modules of the installation license

Screens

System screens

A sample: these are some of the screens for the main features, among the dozens the system ships. The interface is available in Portuguese, English and Spanish, in light and dark themes.

Application Dashboard — Online/offline status of every integrated system, with downtime history.
Application Dashboard Online/offline status of every integrated system, with downtime history.

Security

Security and compliance

Production payloads carry sensitive data: production orders, costs, customer identification. Controlling that data is part of the product.

AES-256-GCM before persisting, without changing the content delivered to the destination. One key per rule, conditional on text and flow direction.

Viewing an encrypted payload requires being on the key authorisation list, re-authenticating with your own password (and 2FA, if enabled) and writing a justification.

Every decryption attempt — allowed or denied — records the user, result, technical reason, justification, affected entity and source IP.

TOTP through an authenticator app, activated per user with a configurable global requirement.

Corporate login as an alternative to local users, without duplicating identity management.

Each screen is a tool released in the role — it governs the menu and the API authorisation, not just the interface.

Outbound credentials and API keys are encrypted at rest and never re-displayed by the API once saved.

All external traffic goes through nginx with TLS; the SAP connectors stay on the internal network only, with no published port, protected by an internal token.

Content-Security-Policy on both domains: scripts, styles and fonts only count when they come from the installation itself. Even the code editor in the screens is served by it, not by a third-party CDN.

How pricing works

One licence per plant. No bill that grows on its own.

The question that stalls any integration decision is whether the cost will grow along with the estate. Here it does not: the number of plants changes the price, and nothing else.

One key per installation. Each plant licences its own, and what runs inside it is not metered.

Five integrations or two hundred, the licence is the same. There is no cap on applications or interfaces.

SAP RFC/BAPI and IDoc, OPC UA, Modbus, MQTT, databases, REST and SOAP all come in the same package.

The volume the plant produces does not change the price. Nothing is billed per event.

The 108 ready scenarios for PP, QM and PM are part of the product, not a separate module.

It runs on the plant own server. There is no cloud subscription, and no data has to leave the factory.

The one optional item

The AI Agent — which investigates the alert on its own, points to the cause with evidence and says what to do — is licensed separately. Everything else is included. We would rather say so here than at renewal.

The licence price is quoted on request, after an assessment of the environment: the size of the estate changes the implementation effort, not the licensing rule. Talk about your scenario

Request a demo

To prove it works in practice, we run an end-to-end demo: we connect CMS to a test SAP system, a simulated OPC UA server, the database and the API, showing the whole integration cycle, from intake to final delivery.

Address
Av. Alfredo Ignácio Nogueira Penido, 335 — Sala 706
Jardim Aquarius
São José dos Campos – SP, 12.246-000

Book a demo

We reply within one business day with a proposed time.

The data you send is used only to answer this enquiry.