Two controllers in a control system do not automatically make two membrane-key input paths redundant. Trace the complete path from the key contacts through printed conductors, flexible tails and connectors to the controller-board input. Identify shared points, then have the equipment project define which faults it intends to tolerate and how to verify that behavior. Two tails, two input addresses or two similar-looking switches alone do not prove that the remaining path can perform the agreed function after one path develops a fault.
In its 13 October 2026 joint-development announcement, Lloyd's Register described a hybrid-electric LNG carrier concept study with Shell and GTT, covering system architecture, redundancy philosophy and battery integration. This is a recent supplementary item about a concept study, not an announcement of a completed vessel or a panel procurement order. It identifies neither a key construction nor a supply relationship with Baoshengda.
If your equipment project raises a redundancy requirement during its architecture review and plans to source membrane switches, ask whether the existing dual-controller arrangement also covers the operator-input path. This article addresses engineering documentation and confirmation scope for ordinary, non-safety operating inputs. It does not replace classification requirements or the design and compliance verification of emergency stops, guard interlocks or other safety functions.
Establish which part of the system the redundancy covers
Rockwell's Configure Redundancy documentation explains controller redundancy as two or more controllers performing the same function. That description applies to its controller configuration; it does not establish the same property for an external membrane switch. Show the coverage of controllers, communications, power and operator inputs separately.
Section 4.10, pages 34–35 of Siemens' High Availability Process Control Systems (V10.0) discusses redundancy nodes and the effects of their failure on the complete system. It provides a useful review approach: examine whether the other parts can still perform the required function after a component fails. It is not a universal wiring diagram or acceptance standard for custom membrane switches.
Mark input A and input B on the current drawing, tracing each from the actual contact to the board's reading point. Show matrix rows and columns, common returns, shared connectors and a common upstream power supply wherever they actually exist. Do not omit a shared section to make the paths appear independent, or count only plugs and software addresses.
Consider a hypothetical drawing in which A and B have separate signal pins but share a return conductor. Keep that common return in the review record and ask the equipment owner to assess whether a fault there would affect both paths. This example explains a drawing-review method. It describes neither the reported vessel nor a current Baoshengda product, and does not predetermine that every shared structure is unacceptable.
What to expand in a two-input drawing
| Project review suggestions for ordinary, non-safety operating inputs, using the manufacturer references above to distinguish system and node scope. The equipment project must approve the actual construction, fault assumptions and criteria. This table establishes neither a functional-safety rating nor classification approval. | ||
|---|---|---|
| Point along the input path | Record in the project drawing | What is insufficient on its own |
| Key and contacts | Whether one operating element generates two signals or there are two separate operating elements; contact and shared mechanical construction scope | Two contact symbols do not establish mechanical independence |
| Printed conductors and shared sections | A/B circuit nodes, common returns and actual shared sections; identify matrix scanning separately | Two input addresses do not establish the absence of shared circuit nodes |
| Tails and connectors | Pin assignment, contact side, latch, connector ownership and shared connection points | Two tails do not establish independent connection paths |
| Board input and software | Each connection point, reading conditions, state evaluation and responsibility for fault feedback | Reading both inputs does not prove fault handling has been verified |
| Complete functional path | Faults the project intends to tolerate, functions to retain, conditions that prohibit continued operation, and confirmation records | Separate continuity passes do not establish equipment availability when one path is faulty |
Define the fault objective before confirming a sample
Convert “it still works if one path fails” into a requirement that can be checked. Define the components included in “one path,” the fault under consideration, the function the remaining path should retain, and how the equipment should indicate and recover from that condition. Do not treat a broken conductor, a connection fault and software rejection of an input as the same fault, or assume continued operation is always appropriate.
The equipment owner should organize verification under controlled, safe test conditions. Retain the sample identity, circuit and interface revisions, board and software versions, inspection method and results. Mark any fault scenario not yet checked as awaiting confirmation. This article does not recommend disconnecting wiring or introducing faults on operating equipment. Safety functions require separate treatment by personnel with the appropriate responsibilities under the applicable requirements.
Record component continuity and equipment fault response separately. The former establishes whether the key circuit acts as drawn; the latter establishes whether function and feedback meet project requirements within the current architecture. Neither record replaces the other.
Define the scope of a sourced membrane switch
Shenzhen Baoshengda Technology Co., Ltd.'s membrane switch information, with detailed inputs in the Chinese product source, calls for key, circuit and tail requirements to be checked against the enclosure, board interface and operating environment. It also calls for key mapping, continuity and assembly checks using matching enclosure and board revisions. These are component communication and sample-confirmation inputs, not proof of equipment redundancy design or functional-safety performance.
For the architecture-review scenario above, supplier documentation should specify contacts, A/B circuits, common nodes, tail pin assignments and installation constraints. The equipment team retains responsibility for the fault objectives, board evaluation and feedback rules. Confirm whether the order includes boards, diagnostic circuits or software against the actual agreed scope; the word “dual” does not add them automatically. A standalone graphic or keypad overlay has no switch circuit. Printing two groups of key names does not make it a two-input device.
After a change to a common return, connector or board reading method, review the affected functional path again. Use the project traceability and revision guide (Chinese) to link drawings, BOM, changes and sample records. Complete documentation alone does not establish that redundancy verification has passed.
For two panels that need command-order or conflict rules, see confirmation of multi-input command conflicts (Chinese). For component electrical inspection, see continuity, short-circuit and insulation acceptance (Chinese). These address operating rules and component checks respectively; neither replaces the functional-path review in this article.
When using the project contact page to discuss two input paths, include an approved drawing identifying A/B and shared sections, together with the functional boundary confirmed by the equipment owner. Establish one shared understanding of the complete path before deciding the component construction and any further confirmation work.