Key Platform Properties
Multitenancy and Project Isolation
Each project runs in its own isolated space, with independent users, devices, settings, and access rights.
This makes it possible to:
- Let multiple customers or departments use one platform instance
- Help system integrators run projects for different clients
- Let development teams work on several projects at the same time
Discretionary Access Control
Cels follows an "everything is denied unless explicitly allowed" model.
- Flexible permissions for each role, from administrator to read-only operator
- Logging of all user actions
- Control over every access to data
- Alignment with corporate security standards
Scalability and Fault Tolerance
Cels can scale according to the number of devices, users, and overall system load.
- No need to manually redesign the architecture as a project grows
- Start with a prototype and scale to thousands of devices without stopping the service
- Infrastructure can adapt to current project needs
- Connected objects keep working through the same normalized model as the hardware fleet grows
Kubernetes-Ready SOA Architecture
Cels can be deployed in a containerized environment based on Kubernetes.
- Automatic service scaling
- High availability and fault tolerance
- Simpler rollout of updates
- Portability between cloud providers
- Alignment with modern DevOps practices
The platform follows service-oriented architecture principles:
- Each service has a clearly defined responsibility
- Internal communication can use gRPC
- Contracts between services can be configured and evolved independently
Cels is ready for hybrid and multi-cloud environments, and can also be deployed on premises for organizations with strict data-security requirements.
AI-Ready Foundation for Machine Learning
Cels provides a prepared foundation for AI and ML scenarios.
- Structured data: telemetry is stored in a unified model with contextual links
- Contextual information: data is connected to objects, time, and location
- Event streams: real-time analysis can be built on live event flows
- ML integration: APIs make it possible to connect external AI services
- AI-driven automation: scenarios can react to AI analysis results
This foundation makes it possible to add predictive analytics, anomaly detection, and process optimization without rebuilding the IoT architecture.
Security
- Two-factor authentication for additional account protection
- X.509 certificates for secure device-level connections
- TLS encryption for data in transit
- Role-based access control for different user types
- Project isolation so data from one project is unavailable to users from another
- Audit logs for user and system actions
Core Platform Services
Gateway Service: Protocol Interoperability
The gateway service connects devices to the platform and turns many device protocols into one normalized internal flow.
The connection is configured through models and objects.
A model acts as a virtual counterpart of the physical device: it describes parameters, commands, and events so the platform can receive incoming data and send the right commands back.
Devices can differ by manufacturer, network, protocol, or payload format.
Cels hides that complexity behind a unified object model, so users are not locked into one hardware vendor or proprietary protocol.
Basic gateway responsibilities include:
- Receiving and routing incoming data with protocol-specific logic
- Sending processed data to internal services or back to devices
- Running TCP and UDP servers where needed
- Serializing and deserializing data from different protocols
- Normalizing telemetry through device models
- Supporting device-to-device data exchange, from one-to-one to many-to-many
- Applying transport-level encryption, including TLS
Handler Service: Data Processing
Cels supports serverless data processing in two modes:
- Real-time processing when data arrives
- Retrospective processing for historical data analysis
Handlers can be used to filter incoming data, enrich telemetry, calculate new indicators, split one packet into several values, transform payloads, or trigger webhooks for external systems.
Several handlers can be linked into chains, where the output of one handler is available to the next.
Basic capabilities include:
- Custom ES6 functions
- Telemetry enrichment, filtering, and transformation
- Webhooks for integration with external systems
- Isolated execution in containers with resource limits
- Interface-based testing and debugging for simpler processing tasks
Automation Service: No-Code Logic
Cels includes a graphical no-code editor for automation scenarios.
Scenarios describe the behavior of an object using finite state machines.
Core concepts include:
- State machine: a process described through states and transitions
- States: stable periods of a process, such as "idle" or "moving"
- Transitions: changes triggered by events or conditions
- Triggers: object data, API requests, other automations, timers, and geofences
- Actions: commands, notifications, tags, tasks, integrations, and other system responses
The editor lets teams define business-process logic without writing code.
Anyone who understands the operational process can build, test, start, or stop a scenario from the graphical interface.
Automation can run on one object or on many objects at once.
One scenario can also use parameters, commands, and events from several models, making cross-device interaction possible inside a single automation flow.
Each automation scenario works independently. Several scenarios can run on the same object at the same time, which makes behavior flexible without turning the system into custom code.
Web and API Layer: Interfaces and Integrations
Cels provides user interfaces and API access for operators, developers, and external systems.
- REST API for integration with ERP, CRM, MES, SCADA, mobile apps, and web services
- Data-driven UI, where interfaces are generated from models
- SDK support for advanced integration scenarios
- Flexible authorization and access control
- Synchronous and asynchronous integration patterns
The API can be used to automate interaction with the platform: collect data, send commands, start an automation scenario, attach tags to objects, or synchronize data with an external service.
For example, if the same command must be sent to a device at fixed intervals, an external application can send requests to Cels automatically instead of relying on manual actions in the UI.
Requests follow REST principles and usually include the platform URL, an access token, an object ID, and a clear request body.
Data Storage
Cels uses different storage approaches for different data types.
- Hot data: in-memory storage for object states and user sessions
- Cold storage: time-series storage for telemetry history
- Specialized databases: optimized storage for telemetry, cache, entities, files, and firmware
This separation keeps current object state fast to access while preserving the historical record needed for reporting, analytics, audit, and predictive scenarios.