The latest episode (S1E28) of the Kenexis Functional Safety Podcast is now available on Spotify and Apple Podcasts

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E28 TRANSCRIPT (Markdown)
Cleaned & reflowed for web publication and AI crawlability.

The JSON-LD block below is schema.org structured data. If your CMS lets you
add raw HTML to a post, paste it into the page (or anywhere in the
body — crawlers read it either way). Fill in PLACEHOLDER_EPISODE_PAGE_URL
once the post exists. Everything from the "# Kenexis Functional Safety
Podcast…" heading down is the transcript body — paste it into your post.
–>

"`html

"`

# Kenexis Functional Safety Podcast — Season 1, Episode 28: IEC 61511, Clause 10.3.2 Bullets 24-29 (SRS Completion)

—

## Introduction, Disclaimer, and Episode Recap

Wow, there are a lot of things in the Safety Requirement Specifications Clause. It's taken us several episodes, but today I think we're finally going to get to finish it all up.

Welcome to the Kenexis Functional Safety Podcast. I'm your host, Ed Marszal, President and CEO of Kenexis. Kenexis 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. Kenexis 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 SC 65.

Before we start, a little disclaimer. I will be providing my opinion on technical and engineering topics. This information is provided on a 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.

Okay, so there are a total of 29 bullet points in Clause 10.3.2. We have gotten through 23 of them. Today, we're starting on 24 and you know what? We're just going to press on through to the end to make sure that we get done today finally with the section so we can move on. Just lots of stuff in this standard, lots of background. This clause in particular, there's so much informative information, background guidance that are really critical to the application of the clause. So we want to make sure you don't miss out on anything. So we're going to go ahead and get through this.

## Bullet 24: Safe State Actions on SIS Fault

Okay, bullet point number 24. Talking about actions. So let's start out with the actual text of the clause.

Okay, so you need to specify actions required to maintain or achieve. A safe state. Okay, well, that's kind of the action of the safety instrumented function. But specifically what we're talking about here is if you detect a fault in the SIS, what do you do?

Now, in previous clauses, in previous bullets in this clause specifically, we've stated that when you detect a failure in an SIS component, you have a decision to make as to whether you're going to continue to operate in the presence of that failure. So you put up an alarm and you expect the device to be repaired within its meantime to repair, as we've already documented and used in our SIL verification calculations. And during that time period, you're going to maintain a safe process by using compensating measures to replace that component. Or you can shut down the plant.

So vote to trip would be the shortest hand way of saying that. So those are the two options that we've mentioned.

But you know what? It's actually more complicated than that. Because, for instance, and kind of the archetype example that I always provide in this case, is that there are situations where when the SIS has failed, you might not necessarily want to move to a shutdown position. You might want to move to a new operating state.

So the example that I give is in the oil refining industry, or even in upstream oil and gas production, there is a sulfur recovery unit, the Klaus reactor, where we're going to burn hydrogen sulfide effectively into SO2. And then that SO2 is going to pass over a catalyst where it's going to condense out into a liquid elemental sulfur. Now, in a lot of oil refineries, a lot of oil and gas production facilities, the sulfur recovery unit is the restriction. It's the critical path. It's the unit that prevents you from getting more oil going through the refinery.

And that's because, well, you know, it was built 50, 100 years ago, and the flow rate was X. And now we're trying to get 3 or 4 X through that same equipment. And, you know, since sulfur recovery units don't actually make you more valuable product, they're just there to help you dispose of the waste that you're generating as you're pushing that product through, they are often the choke point in the refinery's output.

So much so that instead of just contacting the hydrogen sulfide with air to do that combustion, the combustion of the H2S, they spike the air with a little bit of oxygen, pure oxygen, to make the reaction go faster, to allow more throughput in the same vessel.

Now, there's a little bit of a problem here in that if you get too much oxygen through, so you've got too much excess oxygen going through into the catalyst section of the Klaus reactor, you can actually set the catalyst on fire. And that's something that you're going to detect with a high temperature shutdown on the back end of the Klaus reactor. And when you detect that the temperature has gone high, you're going to want to close the inlets to the reactor. And, you know, basically, we're going to put the fire out. So we want to avoid that situation from occurring.

We have a safety instrument and function that will detect it. But when that safety function activates, you stop the input to the Klaus reactor. So because you stop the input to the Klaus reactor, you stop the ability of the refinery to be able to process its waste. And you might need to shut down the whole refinery at this point in time. Or at a minimum, you're going to need to reduce rates or get yourself into some sort of holding pattern. So in this case, a vote to trip is going to have large financial impacts. If your high temperature shutdown on the back end of the Klaus reactor fails.

But at the same time, if you destroy your catalyst, it could be a catastrophic loss financially because you will have to shut down your refinery for a very long time until you can get that reactor repaired.

So what do you do? If I detect a bad PV in my temperature measurement for the high temperature shutdown, shutting down is not a good option. But continuing to operate in the presence of the failure is kind of scary. It's really scary when we're spiking pure oxygen into the reactor, which is only going to aggravate the consequence, make the consequence happen more extremely and faster. So what do we do?

Well, we kind of split the difference.

And if we detect that the temperature, or detect that we have a failure in the temperature measurement in the Klaus reactor, instead of shutting it down, maybe we might want to take a half measure and just close off the pure oxygen that we're spiking the air with and continue operating with just air, which might give you a minor, you know, it might give you a little decrease in throughput of your refinery for a little while, but you're going to take out the risk of, you know, really, really damaging the back end of that Klaus reactor and thus being shut down for a very long period of time.

So in that case, you kind of didn't shut down, but you kind of did have to take some additional action.

So bullet point number 24 is really there to address the situations where the, the response to a bad PV is more complicated than just either vote to trip or don't vote to trip, put up an alarm. Sometimes you need to take additional process actions to minimize the risk while you're in that compensating measure state, shall we say, where we're continuing to operate the plant in preparation for the repair of that failed component.

All right. So that's bullet point 24. We're actually going to come back to this. I'm probably going to remind you of this scenario. I'll probably tell the whole dang story again when we get to clause 11.3 and we're talking about compensating measures in more detail. All right.

## Bullet 25: Mean Repair Time Requirements

Clause number 25 or bullet point number 25 states that you need to prepare requirements. You need to develop requirements for the mean repair time, which is feasible for the SIS, taking into account the travel time, location, spares holding, service contracts, environmental constraints.

Okay. There are a lot of words there, but basically you need to define what your mean time to repair is.

Ooh, I said mean time to repair. Shouldn't have said that. Mean time to repair is persona non grata. It's a phrase that we never use. It's not in the standard anymore. We're not allowed to use it. When we're talking about the actual amount of time that it takes to repair a component, we always say mean repair time because MTTR is a little bit ambiguous. MTTR has two meanings that mean different things. Different people use them in different ways and it just creates confusion.

I talked about this back in definitions that some people think MTTR is mean time to repair. Some people think MTTR is mean time to restore. And well, IEC basically had the the audacity to decide which is correct. And what they decided is that MTTR meaning mean time to restore is correct. And that's going to include the mean repair time. but it's also going to include that time interval between when the failure occurs and when you know it occurs which some people will call the mean time to detect mean detection time. It comes in a variety of names.

So, we're talking about the actual amount of time that it takes to repair. And honestly, the mean time to repair and the mean or mean time to restore and the mean repair time will essentially be the same thing for any SIS component whose diagnostics are very high frequency. So, if you run a scan on a transmitter and each scan you're doing diagnostics and you run your scan every 100 milliseconds, well, on average, that component will be in the failed state for approximately 50 milliseconds, half of the interval, before you know it that it's failed.

But then again, when you add 50 milliseconds to 72 hours, you pretty much still have 72 hours. So, that's why it kind of gets ignored and blended together. But, you know, as the standards committee members, we need to have precision and think about every potential use case out there. So, we are very precise in our language. So, we use mean repair time, not MTTR, which includes the mean time to detection because it's mean time to restore, not mean time to repair.

Okay, so, basically, what bullet 25 says is that you need to document the mean repair time. Now, where do you do this? How do you do this? I don't recommend actually documenting it in the SRS.

That's right. I said it. I mean, that number shows up in so many places that you're just asking for mismatches and discrepancies. So, what I would generally do is I would put into the safety requirement specifications a reference to go back and look at the SIL verification calculations. So, by reference, we're incorporating the SIL verification calculations into the SRS for every component in the safety instrumented system, a mean time to repair will, or a mean time to repair, listen to me, a mean repair time will be specified in that calculation.

Now, if you're using good software, really good software like Kenexis' Vertigo, it's a relational database. So, every component in the SIS has a test interval assigned to it. And, if you want to prepare an SRS report where that mean time to repair is shown on the SRS data sheets, you're more than welcome to. It's the same MRT that's going to show up when you do a SIL verification report. That's the beauty of doing things with sophisticated software that contain relational databases.

But, if you're not using, you know, Kenexis Vertigo, if you're using somebody else's garbage, then what you're going to want to do is just go back and refer to the SRS calculations instead of having two different data fields that in a very, very short period of time are not going to match up. And, also, I mean, I'm hard pressed to find anybody who doesn't use 72 hours for everything.

So, that might be a case for just putting in one general requirement that says it's 72 hours. Now, that's easy for people that are in onshore plants to say, because those things, travel time, location, spares holding, service contracts, environmental constraints, are generally inconsequential. We generally have spares. We have people to do the work. The travel time is going to be, I don't know, 10 minutes by bicycle. But, if you're on the north slope of Alaska or if you're on an offshore platform, you need to think these things through a little bit better.

Realistically, when you're developing your SIS, if you're doing a new plant design, you actually probably need to think through during that FAT process, during, well, during the SAT process, during the validation, before you get things kicked off, you're going to need to actually think about what your new SIS is, what kind spares you normally stock, how quick you can get things from an equipment vendor if you don't have it in stock, and making sure that all those things are contractually guaranteed. Okay, that's bullet point number 25. Let's keep moving along here to bullet point number 26.

## Bullet 26: Dangerous SIF Output State Combinations

Bullet point number 26 says that you need to specify identification of the dangerous combinations of output states of the SIS that need to be avoided, and of course, that's all assuming that there are dangerous combinations of output states. This is actually kind of tricky in that for every individual SIF, you're going to have a set of actions that you take to get you to a safe state. And you might activate SIF number 1, and SIF number 4, and SIF number 10, and each one of them are manipulating outputs.

Now, what happens if when you activate SIF 3 and SIF 19, you've just created a brand new hazard that can result in unwanted consequence? Well, I haven't seen a lot. I could probably list off on one hand the number of times where I've seen activation of a SIF potentially creating a new hazard that you need to worry about.

So, how do you do this? Well, if you have dangerous combinations of output states, you're going to need to determine, you need to define how the SIS is going to detect that situation and how the SIS is going to respond to that situation, and that needs to be written up in the logic. It's probably going to be a special note that is going to be referenced in the cause and effect diagrams when you're laying out your safety instrumented system. But how do you know that this occurs?

How do you know you need to go through that definition of measurement and actions of combinations of dangerous output states?

Well, now we're going back to the original risk analysis, the process hazards analysis of the plant. And this is one of those things that I like to see put into a checklist. Otherwise it's never going to happen. In a

PHA, in most risk analyses, people are kind of focused in a certain mode of operation, a certain deviation, and things get looked at one at a time. Looking at combinations of things doesn't usually happen. So, I like to see a checklist in your PHA that asks about dangerous combinations of output states and that gives the team the ability to kind of look at the SIS. And kind of go one output at a time and say, okay, what did activation of this final element do to the process? And am I generating a new hazard?

So, kind of stepping through one output at a time, looking at what happens when it gets activated and thinking about what position you put the plant for other actions to be able to create a new hazard.

So, it is a requirement. It's something that you don't normally see activated because, you know, usually shutdown is shutdown and, you know, moving a final element to its safe state generally neutralizes a specific hazard. But it is possible you need to do the risk analysis. So,

I recommend putting in a checklist item that requires the team to look at this specific situation. And if you run into a problem, you might need to write specifications for how the SIS is going to detect that situation and respond to it.

## Bullet 27: SIS Environmental Condition Requirements

Alright, bullet point number 27 requires that you create requirements for identification of all of the extremes of all the environmental conditions that are likely to be encountered by the SIS during shipping, storage, installation, operation. This may require consideration of temperature, humidity, contaminants, grounding, electromagnetic interference, radio interference, that's EMI and RFI, shock, vibration, electrostatic discharge, electrical area classification, flooding, lighting, and other related factors.

So, yeah, you need to define what environment the SIS is going to be installed in. And actually, you know, you need to worry about shipping, storage, installation and so on. Especially if you've got spare parts, you need to think about storage and how you're going to install it, how you're going to ship it.

Now, why? Why is this here? Well, we need to, as engineers designing a system, be able to explain to the equipment vendor who's going to supply this equipment what environment we are going to use it in. And here we're talking about environmental conditions, not process conditions, so that the equipment vendor can supply something that is suitable for the environmental conditions that you intend to install the equipment in.

So, for instance, if you are going to install a hydrogen sulfide detector in an atmosphere where it is extremely dry and extremely hot, let's say the desert in Saudi Arabia, for instance, you might not want to use an electrochemical cell, or at least not an older electrochemical cell.

Newer electrochemical cells are getting a little bit better about the environmental conditions, but an older electrochemical cell can basically dry out and become defunct because it's too hot and too dry, which is why in hot, arid applications, at least historically, you've seen a lot of the use of MOS, metal oxide, semiconductor, ! hydrogen sulfide detectors instead of electrochemical cells.

Now, as I mentioned, the vendors, you know, progress onward and upward. They're making better electrochemical cells that are a lot more resilient to this. But my point here is you have to select equipment based on where you're going to install it.

And the equipment vendors know this and they're not going to supply something to you, for instance, that, you know, if you're installing something outside and it can't freeze, freezing it will destroy the component, then when the equipment vendor sees that you want to install it outside and you're here in Ohio, where I am right now, and it freezes pretty solidly every winter, that's not going to be a good choice for a component.

Now, how do you do this? What I don't want you to do is have a checklist item for temperature, humidity, contaminants, grounding, EMI, RFI, shock vibration, ESD,

*[inaudible]*

for each SIF.

Now, that's kind of the way that the standard is written, but that is stupid. Don't do it that way. This is a perfect opportunity for a general requirement to say, these are the environmental conditions of my plant. All of the equipment shall be suitable for these environmental conditions.

And as a matter of fact, most operating companies already have a document. Usually it's called something like a basic engineering design questionnaire or basic engineering design document that already has this information. You can refer to your corporate document instead of even adding it into the general requirements. Your general requirements can simply point to that corporate document that contains this kind of information.

Don't regurgitate it for every SIF. It's wholly unnecessary. Just another reason that some of the other people out there that are in the business of SRS just do a horrible job. One more reason why the SIF by SIF fill in the blank approach is absolutely horrible and you should never use it.

## Bullet 28: Process Operating Modes and Procedures

Okay, continuing on. Bullet point number 28 states that you need to define, you need to specify the identification of normal and abnormal process operating modes for both the plant as a whole and individual plant operating modes. Additional SIFs may be required to support these process operating modes. And an example of operating modes of the plant as a whole, it says plant startup as an example. And individual plant operating modes, it gives the example of equipment maintenance, sensor calibration, or repair.

Now, we just talked about this literally last week, and this is the one where I have trouble wrapping my head around why we have two different bullet points that basically say the same thing. So, if I go back up to bullet point number 21, it says, you need to specify a description of the modes of operation of the plant and requirements relating to SIF operation within each mode. Okay. And then, lo and behold, I get down to 28, and it says identification of normal and abnormal process operating modes and individual plant operating procedures.

Okay, so I guess they kind of added procedures to mode.

So, they're considering like sensor calibration is not mode, it's a procedure. Okay, additional SIFs may be required to support these process operating modes. I don't know, man, I'm gonna stick by my belief that there is no reason to have two separate bullet points here.

Maybe we can combine both of these bullet points into one, or actually, honestly, bullet point 28, says everything that bullet point 21 does, other than saying that you need to describe the mode of operation. So, maybe if we add the bullet point 28, that there needs to be, in addition to identification, a description of the mode of operation, everything in clause 21 is also in clause 28.

Please,

IEC 61511 committee, and listen to me, I'm going to be with them for hours a day. The meeting that's coming up in June in a couple weeks is gonna be in Trondheim, Norway, which I wish I could go out there. Norway is such a beautiful country. I love going there, but too much stuff going on at home, can't make it happen. I got three new employees starting in, at the end of May and the beginning of June. So, that Kenexis team keeps increasing and beefing up to support your needs.

Okay, anyway, it's one of those things that, you know, it's not the end of the world the way that it is, but I will make a note to self to try to bring this up in front of the committee and say, yeah, maybe we need to rationalize a little bit.

## Bullet 29: SIF Survivability in Major Accidents

Okay, item last bullet point, that's right, clause 10.3.2 is just about finished up. All right, in bullet point number 29, we say, or the standard requires that you provide a definition of the requirements for any SIF necessary to survive a major accident, e.g., for example, time required for a valve to remain operational in the event of fire.

Okay, now this is a bullet point that doesn't get a whole lot of attention, and the reason is most people will design their safety instrumented functions in a way that they are not required to survive a major accident, accident.

And that's because the major accident is generally going to sever signal wires or disable pieces of equipment. When pieces of equipment get disabled and desenergized, they will inherently move to their safe positions in the de-energize-to-trip process for designing safety instrumented functions.

Now, that being said, there may be situations where we want to add in a little bit of resiliency to survive major accidents. Now, most of the time, this is more of a separate study, but that separate study is going to result in requirements being placed on equipment that resides in the safety instrumented system.

So, I might have a safety instrumented function, for instance, that's going to detect low flow on the discharge of a pump, and if it detects the low flow, it's going to close, it's going to stop the pump. And, since you stopped the pump, you're probably also going to want to close the inlet valve. Well, it just so happens that that pump might be an ROEIV, Remote Operated Emergency Isolation Valve, that was determined to be required and has its design constraints set by the API 553 standard.

So, if you look in the API 553, there is a section that talks about emergency isolation valves, and the whole purpose behind the emergency isolation valve is that there are certain high frequency, I know you can't see me doing the air quotes, but I'm doing air quotes right now around high frequency leak sources.

So, things that have a higher propensity relatively speaking to leak. So, for instance, pump seals are going to leak more frequently than welded piping connections. So, specifically, we're looking at pumps, we're looking at compressors, we're looking potentially at fired heaters as those high frequency leak sources.

Now, for a high frequency leak source in accordance with API 553, you want to look at the upstream inventory, because if I get a leak on that component and that leak maybe catches fire, I don't want the entire upstream inventory to be able to get fed in that fire to turn a small problem into a company ending catastrophe.

So, how do we get around that? We're going to put in manually activated valves that when it comes to our attention that there is a fire, and generally when there's a fire like this, it comes to our attention pretty darn quick, whether it's cameras, outside operators, the neighbors calling in, what have you. We know that there's a fire, but just because there's a fire doesn't mean we can do anything about it, which is why the standard says. In these situations you're going to want to put in a valve that's going to close.

So, you've got a couple options for how you do it. You need to analyze your system. Is there a valve a safe distance away from the fire? Now, in the standard you're going to see something like 50 feet.

*[inaudible]*

You're going take that with a grain of salt, a big fire. I don't want to be 50 feet away from a big fire. So, the standard does allow you to operate BPCS valves, manual valves that are a significant distance away from where the fire is expected to be, considering the size that the fire is expected to be, based on a release scenario.

Now, that being said, there are situations where you can't put a valve far enough away from the fire. In those cases, you're going to want to use an emergency isolation valve. So, now, for these valves, whether you activate them electronically, so they come with an actuator and maybe some sort of fusible connection that causes it to go to the safe state when it's really hot. You're going to press a push button. Or, there are some companies like Sofis that have hand actuators that you can actually hand crank a valve from, you know, 100 meters away. I mean, don't quote me on that.

Go to the Sofis website if you want more information on this stuff. But, you can hand crank a valve to a closed position with kind of a remote cable connection. Just kind of think about on your bicycle how a lever on the handlebars is able to close the brakes or activate the brakes at the back of your bicycle because there's a cable inside there that's moving.

So, it's something like that, but a lot more safe, a lot more high tech. So, all of that functionality is so that you can activate that valve while the valve is in the fire. And guess what? You might need to spec out extra things like those fusible links like fire proofing, fire proofing of cables, fire proofing of the actuator to allow that valve to be closed for 10, 15, 20 minutes after the fire has started because there is going to be some sort of time delay between when the fire starts and when you know that the fire has happened and can do something about it.

So, now, the detect the fire and close the valve, it actually, it's not out of the realm of possibility that someone would consider that to be a safety instrumented function. Most of the time it's manually activated, but a lot of times that valve is owned by the safety instrumented system and the specifications for the safety instrumented system need to be included in the SRS. So, at a minimum, you should be looking for those valves that are going to function as EIVs and make sure that you spec out all the appropriate fireproofing to make sure that they're going to be able to do their actions.

## Fire and Gas System Survivability Design

Now, some other things to think about like for fire and gas detection systems, an explosion or a fire, fire, but let's go with explosion, it might be capable of moving pieces of equipment and severing signal wires.

Now, when you sever the signal wire, if you're in an energized to trip system on detection, you might have put everything in the bad PV instead of activating the safety instrumented functions that you might want to activate when you detect a gas release or you detect a fire.

So, in that case, you might want to back up your wired signals with wireless signals such that if my wired communications fail, I still have my wireless communications to activate my final elements and vice versa. So, this last bullet point is something that historically has not gotten the level of attention that it really needs to get.

You should probably add a step into your SIS design, especially in your SRS development procedures where you walk through every sensor, every final element, and ask the question, is there a fire, explosion, toxic gas release scenario that could disable this piece of equipment whilst I need it to operate in that scenario, and then that's going to define what you need to do. So, does it need to withstand a fire for a certain amount of time? Does it need to withstand a certain amount of shockwave to where I might want to build it behind a blast wall, for instance, for a measurement?

Something to think through, another step.

Now, a lot of the time, none of your equipment is going to have any survivability requirements because everything's de-energized to drip, but that doesn't obviate you from the need to think about whether or not it does. So, thinking about it needs to be a systematic, structural, documented part of your SRS development procedure, even if the result is quite literally nothing.

## Episode Wrap-Up and Next Episode Preview

Okay, so with that, we're wrapping for today because we finished up clause 10.3.2 and we can move on to, well, we're not going to move anywhere. I've got to be honest. We're still in safety requirement specifications, but we're going to start moving on to application program safety requirements.

So, next week we're going to talk about clauses. I'm going to shoot to get clause 10.3 done in the next installment. That's going to be clauses 10.3.3, 10.3.4, 10.3.5, 10.3.6, which are all related to requirements on application software. And, I'm going to be sticking to the world of limited variability languages, which makes your software requirements a whole lot easier than if you do something silly like try to program your SIS in JavaScript and HTML. So, we'll hit those clauses next week.

Be prepared next week. Put your nerd hat on because we're going to be talking about software. Catch you then.

## Kenexis Vertigo Software Overview

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle 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 open PHA tool for HAZOP and LOPA documentation. Each safety function can then be analyzed by performing a SIL 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.

After the SIL verification calculations are defined, you can build an SRS 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.

After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility.

Kenexis 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.