S1E51 12.3.4 pt2 to 12.3.5

designing your software is what you do before you actually write your software. We're still designing and we will be for a little bit still. Welcome to the Connectsys Functional Safety Podcast. I'm your host Ed Marsel, president and CEO of Connectsys. Connectsys is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems. Connectsys also provides the industry leading suite of software tools, including our best in class vertigo software for SIS Safety Lifecycle Management. In this first season of the podcast, we are going to focus on the IEC 61511 standard doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind the scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC65. Before we start a little disclaimer, I will be providing my opinion on technical and engineering topics. This information is provided on our best effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast. All right, we are continuing on. We're still in clause 12.3.4. This is the application program design and decomposition into modules. So we're putting together a plan effectively for what we're going to do when we actually write our software. So we're designing how the software is going to be written. Now, clause 12.3.4 gives a very long laundry list of all of the subitems that need to be considered while you're doing this design process. We got all the way through L. I think we're on item L. So there's a whole bunch of bullet points under 12.3.4. So I've been giving them all letters, ABC, D, E, F, G, H, I, J, K is the last one that we did and now we're on L. So going as we go through these bullet points and there's 10 more I believe still we need to get through. As we're going through these bullet points, remember that the application program shall address how these requirements are to be implemented. So what are the requirements that need to be implemented and how are we going to design them into our workflow? Not program them, but write the design upon which the program is going to be written. This is going to get simplified a lot in the next version of the software, or in the next version of the standard, but let's continue on. So bullet item L says there's a requirement for how to or how external and internal diagnostic information will be processed and logged. This is actually relatively important because diagnostics occur in different locations at different speeds, four different pieces of equipment and who is doing which part of the process and how information is getting communicated from one place to another is actually quite important and we already talked about this pretty extensively in clause 10.3.2. But once again, you need to write the software to do what you decided. So just some examples. If I'm doing diagnostics on the transmitter side and let's just say I have a pressure transmitter and the pressure transmitter self-diagnosis that it's in the failed state. Well, you need to specify what the transmitter is going to do. And that's going to be a configuration of the field device. Once you decide what it's supposed to do, now you also need to program the safety PLC to respond to what's happening. Now, just as an example, let's say it's a high pressure shutdown. You can configure your transmitter to go off scale high. Just push that current as high as you can go. And that will trigger a trip effectively. So you really at that point in time don't need to do anything in the safety PLC to make the safety function activate. But the most common default setting is for the output of the transmitter to go to a safe known value like 3.7 milliamps is a very common safe known value. Well, if all you do is set your output to 3.7 and you don't configure your logic solver to do something about it, that's a problem because you're basically going to put it into a safe position. I made a position that is not going to cause a trip and it's stuck there. So setting the output to 3.7 on a detected failure of the sensor is actually creating a dangerous condition unless you program the safety PLC to do something about it, which would be to detect that your below the saturation range of the transmitter, which on a 4 to 20 milliamp transmitter, usually they can give you a valid signal down to maybe 3.9 milliamps. So if it's below that, there's something wrong with the transmitter and the safety PLC needs to be configured to know that that is a signal which indicates that the transmitter is failed. You also need to program the safety PLC to do something upon that failure. Okay, this is all kind of par for the core standard stuff for just the input blocks that you'll get from your equipment vendors in either a function block diagrams or ladder logic, but it's something you need to think through, something you need to spec out, something you need to make sure is being done properly. Now another way to detect that a sensor has failed would be a deviation alarm between the SIS and the BPCS if you're measuring the same location. Well, you've got signals coming into two different machines, so you need to decide whether you're going to do that comparison in the DCS, you're going to do that comparison in the SIS, how you're going to enunciate that deviation. So all of that kind of goes into the philosophy of what you're going to do because there are a lot of different options for doing this. Now in the logic solver, you're going to the logic solvers are going to self-diagnose a lot of failures. Well, how do you get insight into that? Do you communicate that information to the DCS? That's an option. Do you simply put up a kind of a common trouble alarm saying that there's something wrong in the safety PLC? You need to go to the maintenance and engineering interface to dig into it and find more details on what's actually gone wrong. That's another very common approach. Those are what this requirement is referring to as internal diagnostics, but what if an external watchdog timer times out? Those are external diagnostics and once again, you need to do something about that. Now watchdog timers timing out is generally not a program issue. That's something where you're going to want to just externally de-energize power going out to the field as the mechanism for responding to that diagnostic. But as you'll see, there are a lot of different options that you have and you need to specify which option you're going to use. Now I would argue that you've already documented all of this in your safety requirements specifications as per clause 10.3.2. Required you to do all of this, but okay. So if we say that we need to document it twice, then hopefully there's double the chance that you'll document it. Maybe. Anyway, so that's kind of the the design of how your diagnostics are going to be processed. So how are they going to be executed? Which components are doing what? How is the signal going to be communicated and viewed? All right, next bullet point in 12.3.4 is M, bullet point M after L. And that is going to be-- you have a requirement for a detailed description of how operation and maintenance engineering interfaces are implemented, including the way in which alarms are prioritized, indicated, and accepted. So yeah, I'm pretty sure that we needed to discuss what our operation interface was back in clause 10.3.2. But alas, it's one of those general requirements. I would put it in the general requirements section if you're using ConnectSisIS, which is the new name for the Vertigo software, which is going to be-- well, actually, it just got announced. But August 1st, the ConnectSis Integrated Safety Suite is going through a dramatic upgrade in its user interface. So the look and feel is going to change. And we're taking that opportunity to rename some of the existing modules. So the name Vertigo is going to be a relic of history. It will simply be ConnectSisIS in the future. So this is a great place for a general requirement in those safety requirements specifications to indicate what are you doing for operation interface, which you already specced out as per clause 10.3.2. The details of maintenance interfaces were not required for you to spec out in 10.3.2. But it's kind of part and parcel of the same thing. So having a general requirement for how are you going to do that is great. And these requirements include the way in which alarms are prioritized, indicated, and accepted. So what priority do different alarms get? How are they indicated? How are they accepted? Now, those last bullet items, the way in which alarms are prioritized, indicated, and accepted. Now we're kind of sticking our feet directly into the alarm rationalization process. And the ISA 18.2 workflow for alarm management, basically alarms that say that the safety instrumented system has failed. So let's say we have a common trouble alarm coming from the logic solver indicating that maybe the temperature in the CPU is too high. That's an alarm that needs to be prioritized. OK, you've got an alarm rationalization process to do that. It needs to be indicated. And well, we've got an alarm design process. So we know where we're going to indicate it and how we're going to indicate it. And how it's accepted, that's part of the standard workflow of design. So there's the diagnostics that get generated in the safety PLC are going to or can generate an alarm. And once you know you have an alarm, now you need to switch gears to your alarm rationalization, your alarm prioritization workflow, to figure out what priority you're putting on that and so on. OK, next bullet item is N. And again, I'm giving these bullet items letters, because that's why I have it up on my screen. I've kind of scribbled them in virtual pencil. They are only bullet points. So if you kind of got lost in what I'm saying here, take your copy of 61511. Maybe you're going to use your Apple pencil, like I did on my iPad or you're going to type some stuff up on the screen, but just put a letter next to each bullet point. So if you did that, we are now on bullet point and LMM. So this next requirement is a detailed description of any application level diagnostics that may be implemented as external watchdogs, application data integrity checking, sensor validation to meet the required. So OK, I'm going to go back out there and say, we did this already in clause 10.3.2. So what we're going to do in terms of the diagnostics to make sure that we are capable of achieving our performance targets is something that definitely needs to be specified. Going back to clause 11.5, we talked about safety configuration. And that safety configuration process should have resulted in the requirement for a lot of diagnostics like wiring outputs to inputs using multiple inputs with comparison diagnostics, watchdog timers. Everything that you do in that respect needs to be documented. Now that might be something that sits in a general requirements. That might be something that sits in a logic solver data sheet. Typically, we would attach a little diagnostic spec to the data sheet of a logic solver device. Or general requirements are another good location to put this type of information. Because logic solvers tend to-- the requirements for logic solvers tend to spill over to all of the equipment in the safety system as a whole. So by definition, anything discussing general operation of logic solver is a general requirement. All right, L, M, N, and then O is the next bullet item. So for bullet item O, there is a requirement for system configuration checks, including the existence and accessibility of the expected hardware devices and software modules. What do you need to do with regards to the design? Hopefully nothing. This is something where you're kind of expecting your logic solver vendor to be able to do all of this automatically based on your configuration. So when you're in the maintenance and engineering interface for your logic solver device, you're doing your programming. Well, before you even do your programming, you're going to set up a configuration of what does all of your equipment look like. And in that, there's going to be what are the CPUs? What are the communication cards? What are the I/O cards? What RAC slot and channel do those cards sit in? What I/O points are going to land in which channels on which cards? So that kind of configuration is essentially the starting point for your safety PLC configuration. Now, what this clause is telling you is that if you inserted an output card where the configuration says an input card is supposed to reside, your system should check this. Your system should know this. And if your system doesn't do this by goodness gracious, get a different system. These are table stakes for even the cheapest PLC. OK, next item up is item P. And it is a requirement. So we're going to define a requirement for how the complexity in the application program design is minimized through the use of modular design and simple functionality. This one rubs me significantly the wrong way. So this is kind of a design philosophy that you might want to put into your corporate design standard. But on a project by project basis, writing a statement for this is what I'm going to do to make sure that my software is as simple as possible. The complexity is minimized. I'm sorry, but that is a step too far. That's a little bit on the ridiculous side. So yes, we absolutely want to minimize the complexity of the software that we're developing. Keep it. It's simple. Very, keep it simple, stupid, connects us integrated safety suite, kiss. It's a, you know, you really shouldn't design your plant without kiss. How about that? (laughs) But this, you know, keeping it simple is a philosophy. It's a training issue. It's a competency issue. It's not something that changes or gets documented on a project by project basis. So, absolutely in your safety requirements specifications, you're gonna be referring to external documents. One of those external documents is going to be a corporate or a site philosophy on how software is developed, how tags are chosen, et cetera, et cetera. That is the place that this type of information should be residing. All right, that was elemental P. Now we are on bullet item Q, bullet item Q, which is a requirement for functions related to the detection, annunciation and management of faults in SIS, sub-systems. Okay, so we need to manage to enunciate and detect faults in the SIS sub-systems. And kind of the overarching theme here is what I talked about when we first started this episode with item L in terms of internal and external diagnostics. Diagnostics can happen in a sensor. We need to communicate those diagnostics into the safety PLC, so that the safety PLC is capable of appropriately responding to what those diagnostics are. Okay, so that type of functionality needs to be incorporated in the safety instrumented system. And it needs to be documented in your specifications in your design, in your plan. So as I, again, as I mentioned in item L, a lot of this got documented because of 10.3.2. These are generally general requirements. So use that, connects SIS portion of the database for general requirements to write down how you're gonna do this because it's probably gonna be done consistently. So the way you communicate a diagnostic and hold the information about that diagnostic and an unseated alarms related to that diagnostic are gonna be consistent for pretty much every input device. It's gonna be consistent for every output device where you have diagnostics. The mechanism for the communication is generally gonna be consistent. So it's just a matter of writing that information down so that it gets done consistently in the software development. And again, good news, more sophisticated, silvery certified logic solvers, your equipment vendor has already thought all this through. And it's part of their library modules that you're going to be able to use. Okay, the next item up, so L, M, N, O, P, Q, R. Okay, so we are at the R subsection and let's do R and S together. R is a requirement for functions related to periodic testing of the SIF offline. And S is a requirement for functions related to the periodic testing of the SIF offline. So R is online, S is offline. If you need the logic solver to participate because of functional, you know, special requirements in the testing process, you need to program those testing capabilities into the safety PLC. So this could be something as simple as the ability to do a bypass. This might be something where you have a toggle where you can decrease the time requirement for a timer to make, you know, a four hour timer condensed down to four seconds. So you're not spending four hours trying to execute a test plan because of some sort of time delay in the system. Whatever information you need, or whatever actions you need the SIS to be able to take that are special, that are simply a requirement of the testing process, you need to write them down so that people are going to be able to code them out. Now, honestly, most of the time, this is just that standard bypass functionality is all you would need to allow testing to occur, either online or offline, but sometimes you might need something a little bit weird. Sometimes you might want to change how the system behaves ever so slightly during a test process. So now, of course, we might be violating the complexity clause there. So I'm gonna think about, but yeah, R and S, if you need special behavior out of the SIS program in order for tests to occur, obviously you need to write that code in. All right, item T, T. So, there's a whole lot of function out there. A whole lot of bullet points here. T is a requirement for functions that allow maintenance of the SIS to be carried out serifly. Okay. Let's do an example of this. If you have a gas detector as part of a safety instrumented function out, every once in a while, you can run into a situation where a gas detector is part of a safety instrumented function. So let's say I have a room that may have toxic chemicals in it, and if the toxic chemical concentration in the room goes high, I'm gonna lock the door so that people can't wander into the room when the toxic concentration is excessively high. That device is gonna need to go undergo very frequent maintenance. So on a quarterly basis, let's say we're using a combustible, I have a combustible gas detector with a catalytic bead, so I'm gonna need to calibrate that quarterly. Well, sometimes I might want to do that automatically. So I might have the transmitter communicate to the SIS that it is going into calibration mode. When it goes into calibration mode, the SIS should ignore the signal until the calibration is done. So you send a signal that you're going into calibration mode, you do your calibration after the calibration is done, you take it out of calibration mode. So that's an example of functionality that is going to allow the maintenance to occur. Now, did we need to do all that extra fancy, fancy programming and safety PLC and make it more complicated? Probably not. You can just as easily use the pre-existing bypass functionality to put the device in bypass and execute the calibration manually. But if you want things, especially things that happen at a high frequency and you're capable of automating them, it makes sense to do that. If you do, you need to write some extra code for that automation. All right, the last, the final bullet point in clause 12.3.4 is you need to specify requirements to document requirements for references to documents on which the application program design specification is based. Now, again, that design specification might simply be an extension of the information that sits in your safety requirements specification that optimally, who would exist in the ConnectSIS software. And part of what we do in the general requirements is going to be incorporation by reference of external documents. So if you have a site standard for how you're supposed to name your very in an application program. You in your SRS, generally you put this in the SRS general requirements, you have that incorporation by reference section, and you refer to that external document there, just let it say that all of the programming needs to be done in accordance with the site programming standard, blah, blah, blah. Also in the new version of ConnectS SIS, that is going to go live on August 1st of this year, you will simply be able to drag and drop a copy of that standard directly into your ConnectS SIS database, so that it can actually reside in there as one of the reference documents. So a lot of good things coming up in the ConnectS integrated safety suite world, including not just incorporating documents by reference, but actually being able to keep a copy of that document directly in the database, if that's what you want to do. All right, so that with that, we have worked our way all the way through clause 12.3.4. You would think at this point in time, we have made sure that we've specified everything that we need to specify before we write our program. My argument, my argument, getting up on my soapbox, all of this should be in a single safety requirement specification. And if you do that in the ConnectS SIS RS software, you're going to be head and shoulders above everybody else. But you'd think that we're ready to write our program yet, but we're not. And you would think that the episode is over, but it's not because there's still another clause, another sub clause in 12.3. So for the final sub clause in 12.3, we have 12.3.5, which in and of itself has four bullet points beneath it. So let's dive in. So clause 12.3.5 states that the application program design shall ensure the design, the specification, the what you're writing down, what you're documenting with regards to how the code needs to be written, how the code needs to be executed, where the code needs to reside. That's all part of the application program design. That design shall ensure four things. The first thing that it needs to ensure, first bullet point, the completeness with respect to the SRS and its intended purpose. So the design needs to be a complete representation of the application program, and it needs to mesh up with the SRS and the intended purpose of the SRS, the intended purpose of the application. Now it's really easy for your application program design to mesh up with the SRS if it is contained in the SRS. Part and parcel, no reason to separate, for most of you out there. Okay, bullet point number two, it needs to, the design needs to ensure correctness with respect to the SRS and its intended purpose. So the design of the SRS needs to be complete, it needs to include all the functionality, and it also needs to be accurate. No kidding, it needs to be complete and it needs to be accurate. I would have never thought of that myself. Okay, all right, I'm going on fun with tangent. All right, let's keep going. Next bullet point, bullet point number three, the application program design shall ensure freedom from ambiguity, i.e. in S, it is clear to those who will utilize and document at any stage of the SIS life cycle. All right, bullet point number three here, I'm breaking into a few pieces and kind of talking it through. So we need to be free from ambiguity, what you're saying and how to implement needs to be clear to anyone who's using this document at any stage of the life cycle. And continuing on, this includes the use of terminology and descriptions which are unambiguous and understood by plant operators and system maintainers as well as the application programmers. So that's kind of interesting in this freedom from ambiguity. What they're basically saying is that your application program design, you should be able to hand it to a maintenance technician and they should be able to understand what's happening. So we're not writing jargon for programmers. We're specifying things in a way that an operator or a maintenance technician will be able to understand what the design is and what the system is supposed to do. But it also needs to be thorough, comprehensive and complete and correct enough for the application programmer to actually write the application code. And item four, it needs freedom from design faults. Okay, so in bullet point two, we said it had to be correct and that's not enough. We said in bullet point four that it has to be free from faults. It has to be correct and free from faults. Oh, well, I was gonna make it correct, but I was gonna leave the faults in there. Come on people, let's, we are sharpening the pencil in the next version of the IEC61511 standard and taking out some of this motherhood and apple pie, duplicative information saying the same thing in multiple different locations, trying to keep things a little bit simple and more easy to implement. All right, with that, we have gotten ourselves all the way through clause 12.3 in the standard. We're getting ready to move on to what is next, which is gonna be clause 12.4 of the standard. So 12.3, we designed the application program, speccing things out, making sure all the information's there. We got all the way to bullet point you in a list. So that is a long list of things that we need to make sure get documented. Most of them were already documented because of what we said in 10.3.2, but it's still there and we're continuing on. But now we have a complete design. We are ready to start coding. So we're not at the stage yet where we're gonna be able to hand the SRS over to clause and let clause code generate the code for us. Not yet, maybe. I wonder if it could probably, it could probably write the program better than the person that you're having where the program now and do it through, I don't know, 10, 15 bucks worth of tokens. But I digress. But I digress. We're gonna talk more about the application program implementation next week. And I'm going to, when I talk about application program design, I'm gonna do this through the filter of a human being, actually doing the design, which is where we are at today. But the time is not when that clause code instance, the clause code work instance is gonna be able to generate this code for you. But alas, we're gonna kind of go old school and still assume that a human's gonna be actually doing the programming. So that's gonna be clause 12.4. I am hoping we're gonna be able to get all the way through clause 10.4 in one installment that is not gonna happen next week. I'm gonna be teaching a training class on ConnectSus open PHA and ConnectS SIS at a new customer. New customer site, actually, they're kind of, we're going to the corporate headquarters 'cause there's 20 plants that are all migrating their data out of these stuff that they used to use into KISS. And I will be teaching them all about it. But the week after that, I will get you a brand new podcast that talks all the way through clause 12.4. If I can get it done, there's a lot of information in that clause. So, I might have to split it into two pieces, but I will not know until I start. So enjoy the podcast and well, it's over now. So I hope you enjoyed the podcast. I will catch you on the next one. Now that you've heard some insights on technical safety, functional safety, and the IEC61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety lifecycle using the ConnectSis Integrated Safety Suite and our SIS Safety Lifecycle Management tool Vertigo. Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems. Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our OpenPHA tool for hasop and LOPA documentation. Each safety function can then be analyzed by performing a cell verification calculation. Complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities. Under the cell verification calculations are defined, you can build an SIS by automatically generating a cause-and-effect diagram from the SIF definitions and other defined instruments. Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. Under the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility. ConnectSis Vertigo is the most integrated, easy to use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application. [Music]