NS Indicator and (Safety) Exlusive I/O connection explicit timeout feature is not integrated correctly

Abstract

The CIP Safety (Exclusive) Timeout feature for CIP Point-to-Point I/O connections introduces a new connection state management behavior that needs attention. Specifically, when a connection in an explicit timeout state is closed, it must be handled appropriately in order to reflect the correct network status.

Currently, there are three connection states: "open," "close," and "timeout." Timeout is treated as a special case of close, meaning the system reports either a timeout or a close, but never both at once.

A new state, "close in explicit timeout," is implicitly introduced when a connection in explicit timeout is closed. This state combines the characteristics of timeout and close but is redundant by design. Despite its redundancy, it is essential to track this state change at least internally (between AP/GCI and Stack Core) to ensure accurate connection statistics counting and derived network status reflection. This is not yet implemented.

Problem statement and Required change

When a connection in explicit timeout is closed (via FwClose or TERMINATE_REQ packet), it should be treated as a "regularly closed" connection. However, the current implementation continues to mark the connection as "timed out" until it is reopened, without recognizing any intermediate close actions. This prevents the AP task from accurately determining the connection's state, connection statistics, and device network status.

To resolve this, the new state should be tracked at least internally. There is a possibility to expose this state change at the API level, making it explicit to the application (it is already an observable state, but not made explicit here). This would require an update to the API, but still it would be the preferred solution here.