DWIS.RigOS.Capabilities.Service.Model 0.0.1-build.4

DWIS RigOS Service Capability Model

Service functions are ADCS functions for discrete service actions. They are not activable functions, controllers, procedures, FDIRs, or SOEs: they do not own the drilling control loop, they do not execute a finite procedure, and they do not define a protective envelope.

The first service functions are:

• WeightOnBitTareServiceFunction
• DifferentialPressureTareServiceFunction
• AutoDrillerGainsTuningServiceFunction

The base ServiceFunction is defined in DWIS.RigOS.Common.Model. The generic TareRequestExchange is specialized by WeightOnBitTareRequestExchange and DifferentialPressureTareRequestExchange so the atomic JSON tare-request semantics are specific to the tared quantity.

AutoDrillerGainsTuningServiceFunction uses three independent auto-driller gains tuning request exchanges:

• AutoDrillerWOBGainsTuningRequestExchange
• AutoDrillerTorqueGainsTuningRequestExchange
• AutoDrillerDifferentialPressureGainsTuningRequestExchange

Each exchange carries one nullable TuningValues group with P, I, D, and Tau fields plus TuningCommand and IssuerId. ADCS bridges may ignore fields that are not supported by a specific low-level interface.

Low-Level Interface

Service functions use LowLevelInterfaceService. The first version exposes two independent boolean tare request commands:

• RequestTareWeightOnBit
• RequestTareDifferentialPressure

Each request has a corresponding scalar signal that carries the requested tare value:

• RequestedWeightOnBitTare
• RequestedDifferentialPressureTare

The actual applied tare values are not part of the service request exchange. They are expected to be available as independent real-time signals:

• ActualWeightOnBitTare
• ActualDifferentialPressureTare

The normal two-way heartbeat pattern is available through ServiceRequesterHeartBeat / MaxRefreshDelayServiceRequester and ServiceHeartBeat / MaxRefreshDelayService.

Tare Recommendation Semantics

Advisors submit tare advices. The DWIS Advice Composer chooses which advice becomes the recommendation to the ADCS and publishes the recommended tare command on the DWIS Blackboard.

At the ADCS boundary, the tare exchange is:

• TareCommand: boolean tare command.
• TareValue: scalar tare value.
• IssuerId: identifier of the advisor or composer source whose request was selected.

These fields are serialized together as one JSON-valued signal. The same structure can represent an advice at advisor level and a recommendation at composer level, while ensuring that a command cannot be paired with a value from another issuer. The ADCS bridge reads the selected request recommended by the DWIS Advice Composer. The ADCS may apply it or ignore it, because the ADCS remains the final authority for all ADCS actions. The actual tare value is continuously written back by the ADCS bridge to the DWIS Blackboard as an independent real-time signal.