Description of the functional characteristics of the CShark software

Identification of the provisioned instance

1. Purpose

CShark is server software for managing parking space, facility devices, events, incidents and information tools. The system is designed for local deployment on the owner's infrastructure and provides a single Web interface for operators, administrators, technical staff and analysts.

The document describes the functions of the provided instance in the variant demo. After installation, a fictitious object Demo Parking “North” is created without a real address and details of a legal entity: one level, two zones and 50 spaces. The delivery includes Device Gateway, mock APS and the necessary emulators.

2. Software composition

Components are delivered as local container images and run via Docker Compose. Internal services do not require connection to an external container registry.

3. Users and access control

The system supports authentication, role modeling, and permission checking for user actions. The composition of available sections and operations is determined by the assigned roles.

Basic custom outlines:

• operator: facility diagram, location statuses, incidents and log;
• administrator: topology, users, roles, settings and integrations;
• technician: devices, communication status and commands;
• analyst or owner: employment indicators and dynamics;
• information screen: limited machine access to the assigned view.

Significant administrative and operator actions are recorded in an audit trail, identifying the user, time, and object of the action.

4. Object topology

The administrator forms the digital structure of the parking facility:

1. object;
2. levels;
3. zones and fire compartments;
4. parking spaces;
5. groups of places;
6. devices and their connections.

The types supported for places are: standard (standard), for people with limited mobility (mgn), motorcycle (moto), service (service) and selected (vip). The ability to charge an electric vehicle is specified by a separate attribute ev_charging. The zones have the following modes: standard (normal), fire (fire), shelter (shelter) and service (service). Place geometry and level background are used when displaying the diagram.

In option demo seed 2026.07.2 creates one level, Blue Sector and Green Sector zones, as well as 50 places with codes DEMO-01–DEMO-50. Among them there are places MGN, EV, moto and service. There are no real addresses, details of organizations and camera footage in the basic demo seed.

5. Operator circuit

The diagram section is designed to monitor the current state of the object. It provides:

• selection of object and level;
• overview of the level and transition to sectors;
• display of occupied, free, unavailable and unknown places;
• location search;
• filtering and controlling the visibility of additional layers;
• viewing a place card and the history of its conditions;
• display of related active incidents;
• transfer of one or more places to a state out of operation with the appropriate permission.

The object and level context is stored in the URL and used by associated analytic views.

6. Reception of events and space status

Device Gateway receives events from cameras and other devices, normalizes them and transmits them to Core via the event bus. Cameras support registration, communication status, heartbeat, zone and location monitoring, and command channel.

If NATS is temporarily unavailable, events received by the Gateway are stored in a local persistent queue and sent when communication is restored. Re-delivery should not create duplicate business events.

The system stores a history of changes in the status of places and uses occupancy snapshots for analytics.

7. Incidents

The incident subsystem provides:

• creating an incident manually or by event;
• list of active and completed incidents;
• acceptance of the incident;
• ignoring with a decision;
• completion of the incident;
• display of place, zone, time and materials;
• updating the interface when the state changes;
• control of processing time and escalation.

The operator's actions are recorded in the incident history and audit log.

8. Visit log

The log provides a list of recorded visits and associated traffic events. The user can view entries and apply available filters. Access to vehicle identifiers and materials is rights-restricted and subject to auditing.

9. Analytics

The analytical section displays:

• summary indicators for the selected object;
• number and share of occupied places;
• employment dynamics;
• historical snapshots of condition;
• indicators for the available time range.

The data area must be explicitly specified: a specific level, object, or collection of objects.

10. Equipment

The equipment registry is used for cameras, gates, fire entrances and emulated devices. Available:

• registering and editing a device;
• viewing class, driver and connection parameters;
• online or offline status and time of the last event;
• diagnostic history;
• sending a supported command with confirmation;
• detection of unregistered cameras;
• linking the device to topology elements.

The delivery includes emulators that allow you to check the circuit of events without physical equipment.

11. Scoreboard and information screens

The information subsystem provides:

• maintaining a register of scoreboards;
• creating and editing templates;
• template preview;
• assigning a template to a specific scoreboard;
• displaying counters of available seats and text messages;
• priority emergency message;
• limited access token for screen client;
• update the status of the assigned screen.

Templates and assignments are stored on the server and do not depend on the operator's interactive session. Full management of shift templates and copying of personal layouts between operators are related to further development and are not stated as a function of the current instance.

12. Administration

The administrative circuit includes:

• users, roles and permissions;
• system parameters;
• topology and geometry;
• device registry and integration keys;
• rules and Webhook subscriptions;
• navigation graph and its versions;
• audit log.

Change operations are protected by permission checks. Service secrets are not displayed in clear text in the user interface.

13. Integration capabilities

Core provides an HTTP API based on the published OpenAPI schema. Device Gateway supports event contracts and hardware commands. For external systems, API keys, Webhook delivery and re-delivery of unsuccessful messages are provided.

Main types of integration data:

• condition of the parking space;
• vehicle surveillance;
• condition of the camera, gate and fire entrance;
• change of incident;
• changing the zone mode;
• command to the device or screen.

14. Observability and diagnostics

The system provides:

• readiness endpoint /api/health;
• container statuses;
• Prometheus technical metrics;
• Grafana dashboards;
• centralized Loki logs;
• distributed Tempo traces;
• delivery and event processing counters.

Observability is intended for diagnostic purposes and is not a replacement for backing up business data.

15. Protection and stability

The instance implements the following measures:

• role-based access control;
• individual database roles;
• unique secrets of the instance;
• limited rights to configuration files;
• logging actions;
• checking the database schema before running Core;
• Gateway permanent queue;
• persistent stream of events;
• checksums of the kit and local images;
• Database and media backup.

16. Boundaries of the current instance

Current kit:

• designed for Ubuntu Server 24.04 LTS AMD64;
• does not support ARM64;
• installed in a local container circuit;
• in option demo creates only a fictitious demonstration parking lot without a real address and details of a legal entity; option clean does not create demonstration parking lots;
• does not include industrial integration with specific equipment without its configuration;
• does not state automatic updating from the user interface;
• does not claim billing or charging station management as a feature of the instance provided.

17. Functional accessibility control

After installation, check:

• user login;
• availability of sections according to role;
• creating a basic topology;
• receiving an event from the emulator;
• change in the state of the place;
• creating and processing an incident;
• visit log;
• analytical summary;
• device status;
• creating and assigning a scoreboard template;
• audit trail;
• metrics and system logs.