SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

A pilot that works is not a solution that scales.

Most IoT projects stall not in the pilot but during scale-up: device identity, firmware updates and the data model were never designed. Sanal Çekirdek builds the platform assuming scale.

Ten devices can be managed by hand. At a thousand, every manual task becomes the operational load that stops the project.

Device identity and lifecycle

Every device needs a unique, verifiable identity; a shared credential cannot be managed at scale. Provisioning, updating, replacement after failure and decommissioning are designed as one lifecycle.

  • Provisioning runs through an automated flow, not by hand
  • Identity belongs to the device, not to the fleet
  • Identity transfer on replacement is defined
  • A decommissioned device loses access immediately

Data model and meaning

Devices from different vendors report the same measurement under different names and units. Without a common data model, every new device type creates another integration project.

  • Units and time zones are normalized at source
  • A new device type maps to the model, not to code
  • Measurement meaning is defined in a dictionary
  • Version changes preserve backward compatibility

Edge processing and connectivity

Assuming connectivity is always available does not survive the field. Buffering, retransmission and prioritization at the edge are part of the design; a critical alarm should not queue behind bulk telemetry.

  • Critical alarms travel at their own priority
  • Buffering engages at the edge when the link drops
  • Retransmission does not create duplicate records
  • Link cost is planned alongside data volume

Integration and firmware updates

A platform does not leave data where it lands; it feeds maintenance, production and business intelligence systems. Remote firmware update is a security requirement: a fleet that cannot be updated is a gap that cannot be closed.

  • Updates roll out in stages and can be reversed
  • A failed update does not leave the device unusable
  • Integration carries feedback, not one-way flow
  • Interface versioning is independent of the fleet

How we work

  1. Set up device identity and the provisioning flow
  2. Define the common data model
  3. Design edge processing and buffering
  4. Build staged remote updates
  5. Complete integration with business systems

How success is measured

  • Provisioning requires no manual intervention
  • A new device type can be added without code changes
  • No data is lost when connectivity drops
  • The entire fleet can be updated remotely

Frequently asked questions

Off-the-shelf platform or our own?

Device diversity and scale decide. With a limited set of device types at moderate scale, an off-the-shelf platform is faster; where many proprietary protocols exist, the integration layer is designed separately.

Where will our data be held?

By data class and latency need. High-frequency raw data usually stays at the edge or on site while summary and decision data sits centrally; the placement decision is written down separately.

Why is moving from pilot to scale so hard?

Because tasks done by hand in the pilot were never automated. If provisioning, updating and replacement stay manual, operational load grows in step with device count.

Before taking a pilot to scale, let's settle device identity and the data model — that is where the difference is made.

Review your path to scale