Will S+ Engineering 2.1 Detect Duplicated TSTALM Blocks?
Our clients would like to know if S+ Engineering 2.1 (the POSTGRES SQL form) will protect them from potentially significant oversights with respect to TSTALM blocks.
In Composer and earlier EWS programs, the block number to be tested must be manually entered as the value of Specification S1. A common error happens when working logic is cloned. The block numbers involved are usually correctly changed. However, the new value needed for S1 is sometimes overlooked. The result is always two errors:
1. The intended (new) block is never tested, so it cannot trigger the intended action.
2. The original block is tested and will trigger an action that is not intended.
In a scan of 345 systems, this error was found for 125 projects, with 1079 instances, each involving two or more blocks. Instances of as many as six errors involving the same prototype logic have been found in running systems. In a client site visit, we isolated this as the exact cause of phantom operation of a valve. Unintended actions can certainly be as serious as actions that do not happen as intended.
DBDOC detects this situation in a useful way to protect client systems. Composer does not detect this. What about S+ Engineering 2.1?
Voted best answer
I can't help with S+ Engineering 2.1, but the use of tuning lines and the block manager spec synch function can address this problem with current versions of Composer. While it is not a fully automatic process it does remove the manual entry requirement not only for the target block, S1 but also alarm condition, S2. From memory the block manager is part of the standard Composer product from version 5.0 but was an option on earlier versions.