Equipment · material · process
Physical relationships
Represent supply, flow, conversion, location and containment, including direction and validity. A steam network, a production batch and an equipment hierarchy need different relationships.
Be Water Core · Features & specifications
Core · Industrial context and engineering calculations
Industrial foundation · New Be Water release in developmentCore team members have delivered iDOS data platforms and specialist applications in industrial projects. Be Water is developing that technology, those models and that delivery experience into products that are easier to deploy, upgrade and maintain.
Core brings industrial objects, data quality and engineering calculations together as a foundation for applications. Review the planned features, interfaces, deployment options and reference workloads for use with Work, existing systems or partner applications.
Software features at a glance
| Function | Planned capability | Configuration boundary |
|---|---|---|
| Industrial objects & facts | Objects, physical relationships, calculation dependencies, responsibilities and versioned facts with effective dates | Build the objects and relationships needed by the selected application; a complete factory model is not a prerequisite. |
| Data preparation & quality | Source mapping, unit and reference-condition checks, timestamps, operating state and quality propagation | Keep measured, calculated and estimated values distinct; retain source values and mapping versions. |
| Engineering calculations | Formulas and rules, statistical and forecasting methods, dynamic process models, constrained optimization | Each package declares inputs, applicable conditions, dependencies and a professional maintainer. Complex solvers and external models are qualified separately. |
| Model lifecycle | Versioned packages, historical replay, candidate evaluation, shadow operation, controlled promotion and rollback | A candidate can be evaluated without obtaining permission to act on equipment. |
| Configuration & development | Object and relationship editing, mapping proposals, parameter and result inspection, SDKs and test tools | Stable configuration views serve regular work; code and debugging tools support development. |
| Access & governance | Tenant, site, object and action scopes; enterprise identity integration; model and data-use permissions | Read, calculate, simulate, publish and request-action permissions are distinct. |
| Operating visibility | Source freshness, model failures, queues, resource use, dependency health and version status | Inspect data-quality failures separately from service failures. |
This is the planned Core software scope. The delivery configuration identifies the modules, model packages, connectors and compatibility versions included; the table is not a list of already released software.
More than an equipment tree
A useful calculation needs to know what a value describes and how that object relates to the operation. Model the part of the operation the selected work requires, then extend it as the work grows.
Input · method · result
Calculation dependencies
Keep track of which observations, parameters and model versions produced a result. Physical loops and calculation feedback are represented separately.
Task owner · approver · executor
Work and responsibility
Link each operating object to the people, roles and tasks responsible for it. Preserve the responsibility history when shifts or contractors change.
Objects retain stable identities across source systems. Effective dates and recorded revisions allow a later correction without erasing the evidence used for an earlier decision.
Keep the meaning beside the measurement
| Context | What needs to be known | Why it changes the result |
|---|---|---|
| Identity & origin | Site, object, source system and mapping version | Two similarly named signals may belong to different equipment or sites. |
| Quantity & units | Original value and unit, quantity type, conversion and reference conditions | Gauge and absolute pressure differ; standard gas volumes need their temperature and pressure basis. |
| Time | Source and receiving times, sample interval and relevant process delay | Clock alignment does not remove the time material or energy takes to move through a process. |
| Quality & uncertainty | Source quality, missing or stale values, calibration and known uncertainty | A held value is not a new measurement. Measured, calculated and estimated values need distinct treatment. |
| Operating conditions | Equipment state, isolation, process mode and applicable limits | A model valid under one operating condition may be unsuitable under another. |
| Evidence version | Input snapshot, document version and model run | A reviewer needs to be able to inspect the basis of a result and distinguish a later revision. |
The planned runtime checks required inputs and propagates their quality into results. Missing reference conditions or an unsuitable operating state can block the affected method while unrelated work continues.
A professional method becomes a maintained capability
Core is designed to run formulas and rules, statistical models, dynamic process models and constrained optimization. Each method needs an explicit scope and a maintainer; a model file alone is not a working industrial capability.
Define the method
Specify inputs, units, reference conditions, valid operating range, parameters, outputs and the specialist responsible for the method.
Check the inputs
Select an appropriate data window and verify quality, freshness, state and required relationships before computing.
Run with explicit dependencies
Order dependent calculations and handle dynamic state, feedback and process delays. Retain input snapshots and versions.
Review the result
Expose assumptions, quality, constraints and failure conditions. An optimization proposal remains distinct from permission to act.
Maintain and improve
Compare against reference examples and observed results, detect drift, evaluate candidate changes and approve promotion or rollback.
Customer and partner models can remain in their existing services. Planned integration routes include APIs, containers and qualified FMI/FMU adapters; compatibility and runtime requirements are determined for each model.
Interfaces, data formats and SDKs
| Interface or integration | Planned specification | Integration conditions |
|---|---|---|
| File & batch input | CSV, Parquet, JSON and database/API batch reads; Excel through a restricted parser | Excel macros are not executed. Initial reference import scope: files up to 1 GB and batches up to 1 million rows; larger inputs use chunked asynchronous processing. |
| Existing data platforms | Historian/API queries, external object references, on-demand caching and incremental synchronization | Existing systems can remain the source of record; source limits, timestamp quality and cache freshness are recorded. |
| HTTP API | OpenAPI 3.1 and JSON Schema; object, observation, calculation and result interfaces | Separate read, simulation, registration, publication and action-intent operations; asynchronous work returns a run reference. |
| Events | Versioned event schemas with event identity, sequence, event time and trace reference | Tenant/site/type separation; at-least-once delivery with consumer deduplication. |
| Developer SDKs | Python and TypeScript; typed interfaces, unit helpers, examples and simulation tools | Target compatibility covers the current and preceding major SDK version. Exact runtime and dependency versions belong to the deployment compatibility matrix. |
| External professional models | REST/gRPC services, signed OCI containers and qualified FMI/FMU adapters | Initial FMI integration focuses on FMI 2/3 Co-Simulation. Solver, state, timing and license requirements are qualified for each model. |
| Identity & tool adapters | Enterprise OIDC/SAML through a qualified identity service; optional MCP adapters over governed APIs | MCP does not expand the caller’s data, calculation or action authority. |
Interfaces and formats are target specifications. Model adapters, source-system versions and dependencies are confirmed for the selected deployment; format compatibility does not establish the validity of a professional model.
Deployment and runtime environment
| Option | Runtime arrangement | What to establish |
|---|---|---|
| Regional SaaS | Regional managed services and approved external integrations | Data location, allowed destinations, source connectivity and the selected service scope. |
| Customer private cloud | Core services within the customer’s selected cloud environment | Identity integration, network paths, database/object storage, backups and operational ownership. |
| Site server | Local services and storage; Linux x86-64 is the reference host environment | Host, storage and network qualification for the selected workload, plus backup and recovery arrangements. |
| Limited Edge runtime | A local subset of object and calculation services alongside Edge | The included capabilities and resource budget; this is not automatically the complete standard-site Core profile. |
| Existing industrial platform | Selected model runtime, capability packages and adapters alongside the current platform | Responsibility for each data field, source interfaces, model dependencies and which system retains each record. |
Data residency and external service routes are selected explicitly. Operating-system, database, container and connector versions are fixed in the configuration compatibility matrix rather than assumed from these deployment categories.
Resource and workload reference profiles
| Profile | Reference resources | Workload to validate |
|---|---|---|
| Lightweight site | 8 vCPU, 32 GB RAM and 1–2 TB storage, or a qualified E-M local runtime | Reduced object/model scope or retention, especially where an existing historian holds the data. This is not the full CL-1 workload. |
| CL-1 · standard site | 16 vCPU, 64 GB RAM and 8 TB usable storage; Linux x86-64 | 50,000 objects, 500,000 relationships, 20,000 points and 5,000 updates/s; 100 registered and 30 concurrent users, with 20 ordinary API requests/s and declared small-model work. |
| CL-10 · regional deployment | Initial sizing: six workers, each 16 vCPU and 64 GB RAM; separate three-replica database/object-storage services | Up to ten CL-1 sites, an aggregate 50,000 updates/s and 100 concurrent users. Upload policy, storage retention and independent capacity qualification determine the final cluster. |
All figures are untested target/reference workloads. Resources and workload must be qualified together with permissions, queries and model execution enabled. The 8 TB figure is usable capacity after redundancy, not a sum of mirrored disks. Storage I/O and bandwidth require qualification; video, raw high-frequency waveforms and large simulations are outside these standard profiles.
Operation, recovery and portability
| Area | Planned behavior | Configuration or handover detail |
|---|---|---|
| Model state & restart | Checkpoint stateful models; check parameters, state versions and missing inputs before resuming | Reinitialize the model or observe the process when stale state cannot safely represent current conditions. |
| Backup & recovery | Daily backup with incremental options; restore configurations, objects, model versions, permissions and evidence | Single-host, redundant and site-disaster arrangements are distinct; agree the backup location, replacement environment and recovery scope. |
| Retention | Reference policy: 30 days of raw site time series and 13 months of minute aggregates | Retention can be adjusted; models, configurations and important work evidence follow the agreed policy. |
| Updates & compatibility | Version code, models, configurations, dictionaries and connectors with a shared compatibility matrix | Use change impact to identify affected applications; promotion and rollback preserve compatible versions. |
| Customer export | JSON, CSV and Parquet with schema descriptions | Export objects, relationships, units, timestamps, customer data/configuration, model-run evidence and license-permitted model files. |
| Delivery materials | Deployment manifest, object/data schemas, interfaces, declared packages, API/SDK materials and compatibility matrix | Include backup/recovery and export tools, sample data and maintenance responsibilities. |
Recovery commitments and maintenance periods are set for the selected deployment. Reference retention is a design choice, not a universal legal retention rule; licenses continue to govern transferable model files.