Service Profiles¶
A Service Profile is the managed operating definition for one L2Proxy protection service. It combines the approved Policy Profile with the industrial access path, inspection mode, event handling, and service-specific operating settings.
What a Service Profile governs¶
| Industrial concern | Profile responsibility |
|---|---|
| Protection purpose | Identifies the user, plant area, asset group, or activity served by the profile |
| Policy | Selects the complete Policy Profile to be enforced |
| Placement | Identifies the protected industrial access path or observation point |
| Operating posture | Chooses inline enforcement, passive observation, or offline analysis |
| Protocol inspection | Uses the required industrial decoder and approved inspection scope |
| Evidence | Controls local logging and central event archiving |
| Service lifecycle | Provides the persistent configuration for an independent L2Proxy instance |

Figure — A Service Profile governs standalone enforcement placement and operating mode.
Complete profile management¶
Authorized operators can:
- create a new Service Profile;
- inspect all saved profiles in one service inventory;
- select and edit an existing profile;
- save current changes;
- discard unapproved edits;
- use a reviewed profile as the starting point for a new profile;
- assign or change its Policy Profile;
- remove a profile after its service has been stopped.
Using an existing profile as the starting point is useful when several users or plant areas share a common operating design but require different Policy Profiles or protected paths.
Independent service identity¶
Every saved profile corresponds to its own L2Proxy service instance. The inventory shows the profile name, current state, activity duration, operating mode, and configuration summary. This gives operations a direct answer to three questions:
- Which protection services exist?
- Which services are currently active?
- Which operating and policy profile belongs to each service?
Industrial naming practice¶
Profile names should communicate purpose rather than implementation.
| Purpose | Example profile identity |
|---|---|
| Remote vendor | Packaging-Line-2 Vendor Access |
| Substation engineering | F12 Protection Engineering |
| Transformer maintenance | TR1 Maintenance Protection |
| DER operation | DER-5 Intertie Operations |
| Commissioning | North Bus Passive Commissioning |
| Investigation | Feeder Event Offline Review |
Configuration depth without customer complexity¶
The service includes detailed controls for its protected path, inspection behavior, local records, and central event archive. These settings are available to authorized OT administrators, but they do not need to dominate policy review. Operations and engineering can review the service by its purpose, assigned policy, state, and evidence while specialists maintain the deeper implementation settings.
Change boundary¶
A Service Profile is separate from its Policy Profile:
- changing policy content is a policy-engineering decision;
- selecting that policy for a service is an operational assignment;
- starting or restarting the instance is an activation decision.
This separation makes responsibilities and approvals clearer and prevents a policy edit from becoming an unreviewed service change.