From my experience1. Context
You are working in complex production facility. It is basically big corporation and Automation Department is divided for several teams, each managing different part of the system. There is SCADA team that manages all the visualization of production process. There are also different subsystems downstream managed by different teams and You are custodian of one of them.
2. Objectives
SCADA team requests You to invert one bit in Your controller without impacting functionality of the logic. They are expecting to see that downstream device is in alarm rather that displaying healthy status.
3. Logic
You are working on live system which basically means that the logic had already been implemented by those who worked on the system before You. Your PLC logic looks like on Figure 1.
Figure 1 - original logic
The controller polls for data from an IED via two independent communication channels. In IED there is a register that keeps updating and with every controller poll, new value is obtained and stored in IED_COMx_LIVE_WORD, x={1,2}. Controller polling is set for 500 ms. Logic from Figure 1 compares LIVE_WORD with its previous value (LIVE_WORD_PREV) and if a difference is detected, timer TON is starts counting counting again. After comparison is done, value of LIVE_WORD is stored in LIVE_WORD_PREV for further detection of register change. It register is not updated even once within 3 seconds, timer output is set. For more detailed explanation please refer to Basics -> Communication status article.
4. Data
INPUT:
WORD: IED_COM1_LIVE_WORD, IED_COM1_LIVE_WORD - counters that keep changing (data from outside of controller)
INTERNAL:
WORD: IED_COM1_LIVE_WORD_PREV, IED_COM1_LIVE_WORD_PREV - previous values of counters
BIT: IED_COM1_LIVE, IED_COM2_LIVE - represent communication status. If the value of counters stop changing, it means that there is some kind if problem with Your device or communication between Your PLC and device.
OUTPUT:
BIT: IED_SCADA_LIVE - general communication status for SCADA
Conditions:
For all the Figures displayed in this article it is considered that LIVE_WORDs are being constantly updated at 500ms rate. It means that there is a device downstream which works properly and communication between it and PLC is working fine.
5. Analysis
5.1 The simplest solution
Well, let's invert required bit and it' done. Super simple!
Figure 2 - logic with inversion of IED_SCADA_LIVE
You can keep it like that and I guarantee You that when You come back to this logic in few months You will be scratching Your head asking Yourself why it is so hard to read. Let's see... we have inversion on the timer output TON.Q and inversion on OR block output. If I need to invert logic that is already inverted, my first thought is: "Can I simplify it"? The answer is: "Yes".
5.2 Intuitive approach
"If there are two points where data are inverted, inversions cancel out" - this is one of the recommendation I got from a member of my team. Let's analyze this statement. If we cancel out inversions, the logic would look like this.
Figure 3 - suggested modification
Nothing's wrong at the first look. But let's see truth table for Figure 2 and Figure 3.
Table 1 - truth table for Figure 2
Highlighted row is the case shown on the figure.
In case both counters are being updated, or both counters are not being updated, the result didn't change. But for the other two cases result is different. It means we have just accidently changed functionality of our logic! What are the consequences of that mistake? In the original logic, it is acceptable to lose one source of data. In the suggested logic modification, it is not. That may have a huge impact on SCADA and its logic.
5.3 Mathematical approach
It is really easy to forget that mathematics, especially Boolean Algebra, is Your friend, so let's us it.
Basic logic rule says that:
Applying it to our case:
Original logic
Logic with inversion
so
Correct simplified logic on Figure 4.
Figure 4 - correct logic modification
5.4 Other concerns
Finally! We have our logic changed correctly although we didn't say a word about tag names we used. Look at the logic from Figure 4 once again. We know that LIVE_WORDs keep changing (section 4. Data -> Conditions) so we know that our device is responding correctly and we obtain data correctly. But we also see that LIVE bit is 0 which would suggest that device is not alive or there is a communication problem between our PLC and the device. The thing is that when we changed logic, we forgot to adapt tag name to match our modification.
Final modification (including tags adaptation) on Figure 5.
Figure 5 - final logic modification
6. Summary
It may seem that this is some kind of academic analysis. Why would inverting a bit be so important? Well, it may not be. It all depends on perspective. If You work on simple, standalone systems, it may not be an issue at all. You would simply make a mistake and probably just display wrong value on Your HMI or SCADA. But imagine that You work in Oil&Gas industry. Imagine that an IED mentioned in the logic is a Protection Relay for 10kV compressor that pumps LPG to the pipeline. Imagine that SCADA needs to shut down the compressor for the safety concerns when they can't monitor its status. That small, unrelevant peace of modification may lead to serious consequences causing compressor trip and losing millions of dollars.
Try using math to solve Your problem. That may save You from errors and will definitely save Your time - no need to invent a wheel from new.
Don't underestimate any modifications, no matter how easy seem for the first glance.