jbelland, Author at Isograph

Tech Tuesday: Network Availability Prediction 2.0

Posted on March 17, 2015 by jbelland

Howdy, folks. Jeremy mentioned it was coming a few months back, but now it's finally here! The Isograph Network Availability Prediction (NAP) 2.0 official release happened under our noses a few weeks ago. I wanted to talk about this product and the new updates to it.

Network Availability Prediction (NAP) 2.0 features an updated user interface, sharing common functionality with the Reliability and Availability Workbench products.

NAP is one of our lesser-used products. It's not as common as Fault Tree or RCMCost, so I'll introduce you to it first, in case you haven't heard of it. NAP is an extension of the analytical RBD methodologies found in Reliability Workbench. It's based on an RBD, but the RBD features have been expanded a great deal in order to allow modeling of telecommunications networks. These Network Block Diagrams (NBDs) differ from RBDs in that they allow for two-way connections and sockets.

In traditional RBDs, a connection only allows for a one-way logical flow, and each block diagram must have a single input and output. This makes the block diagram evaluation simple, but makes it difficult to evaluate complex communications networks. NBDs are an expansion of that. The two-way flow along connections allows more complex systems modeling, and sockets allow each block diagram to have multiples inputs and outputs. When evaluating, NAP will find all valid paths through the system, from the top level source to target nodes. The network diagram must still have a single source-target pair at the highest level; this is how availability is measured. Once it's identified all paths, then it will determine the cut sets that would block all possible paths, much like an RBD.

An example of a complex network element. The four network interfaces are each sockets, meaning any one of them could be used as an input or output to the network. The undirected connection means an availability path can be found going in either direction.

NAP also features a Parts library. Failure data is entered for these parts. In addition to standard failure rate or MTTF, which are quantities allowed in RBDs, NAP also has a Cable part type, which measures failures in cuts per distance per time. This makes it easier to model failures associated with the cable connection between two network elements. The Parts library also makes it easy to do "what if" analysis, by swapping similar components in and out of the block diagram, to evaluate how using a different BOM could impact the network availability.

NAP 2.0 represents the first update to the NAP software in several years. We've update the program to use the .NET framework, like our Reliability Workbench and Availability Workbench programs, which increases compatibility with modern Windows operating systems, and provides a more up-to-date user interface. It shares many new elements with our other applications, such as the Report Designer and Library facilities. Now, any NAP project can be opened as a library to facilitate sharing information between project files. Libraries also allow you to create common network elements and drag and drop them into your block diagram as needed.

NAP 2.0 is available exclusively as a 64-bit application.

Additionally, NAP 2.0 is in the first line of 64-bit applications we've ever released. You may have heard mention of 32-bit vs. 64-bit apps, or seen it in the context of Windows, e.g. Windows 7 32-bit version vs Windows 7 64-bit version, but not necessarily understood what exactly that means. It might sound a little bit like the computer nerd version of two car guys out-doing each other about the engine displacement of their muscle cars. "My '67 Camaro has a 283 cubic inch small block V8." "Oh, yeah? Well my '69 Challenger has a 426 Hemi!"

Basically, it refers to the amount of memory that can be accessed by the program or operating system. As an analogy, imagine a city planner designing a road and assigning addresses to the houses on the road. If he uses three-digit addresses for the houses, then the street could be a maximum of ten blocks long. However, if he uses four-digits, then he could have 100 blocks on a single street. Three digits may be all he needs for now, but if there are plans to further develop the neighborhood in the future, he might want to use four digits for the addresses.

Computer memory works similarly: the number of bits for the operating system or the application refers to the number of blocks of memory that can be addressed and used. The maximum amount of memory you can address with 32 binary digits is about 4 gigabytes. Back in the mid-90s when the first 32-bit processors and applications were developed, that was an obscene amount of memory. However, the future has come and gone and now we can max out a computer with 32 gigabytes of memory for a little over $200. 32 bits is simply not enough to address all that memory, so about a decade ago, computer hardware and software began transitioning to 64 bit addressing. The maximum theoretical amount of memory you can address with 64 bits would be 16 exabytes (or about 16.8 million terabytes), although practical limitations with the hardware make it a lot lower. In other words, we don't have to worry about maxing that out anytime soon.

Honestly, I'm not sure I completely understand this either, but my Camaro has a 346 cu. in. small block V8!

Even if you were using a 64-bit version of Windows, a 32-bit app could only use a limited amount of memory. After the operating system takes its cut, the app is left with about two GB to work with. Most of the time, that's fine. If you're building a small- to medium-sized fault tree, that's more than enough. But NAP's undirected connections and sockets make path generation a complex affair, and the number of cut sets can increase exponentially with regard to the number of paths. More than any of our programs, NAP users were crashing into the limits of 32-bit computing, so this program will benefit most from the 64-bit version.

While the latest release of Reliability Workbench (12.1) comes in both 32- and 64-bit flavors, NAP 2.0 is only available as a 64-bit app. So knock yourself out and build the most complex network model you can think of. The only limitation is the hardware constraints of your computer!

NAP 2.0 is available as a free upgrade to users with a NAP license and current maintenance. Contact Isograph today to download or to renew your maintenance.

Tech Tuesday: Reliability Workbench 12

Posted on September 23, 2014 by jbelland

Howdy, folks! Isograph has recently launched Reliability Workbench 12, the latest incarnation of our flagship reliability analysis product. There are a number of new features and improvements, and today I'll be talking about a couple big changes.

The first and biggest change is the addition of a new Safety Assessment module. This new module allows users to perform Functional Hazard Analysis, PSSA analysis, and other safety assessments in accordance with SAE ARP 4761 and other similar standards.

The System Safety Assessment (SSA) module allows users to construct a functional failure mode hierarchy, similar to the FMECA module of Reliability Workbench, or the RCMCost module of Availability Workbench. This functional hierarchy will list the functional requirements of the system, and the functional failures that could inhibit the system's ability to perform the functional requirements. So for instance, an aircraft braking system could have several functional requirements, such as control thrust, control aircraft on the ground, and decelerate aircraft on the ground. The "decelerate aircraft on the ground" function could fail if there is a loss of deceleration capability.

Each failure can produce an effect. In our aircraft braking example, effects of failure of the braking system could be runway overrun, in which the aircraft is not able to completely decelerate the aircraft before the end of the runway. Then, each effect can have a user-defined classification, such as minor, major, or catastrophic. You can further define phases and conditions and tell the program that the effect only occurs during a particular phase or phases, and under specified conditions. For instance, the effect of a failure mode on an aircraft may only occur during take-off and landing, or in icy or wet conditions.

So far, so good. This isn't too different from what many users already use FMECA or RCMCost for. But what differentiates the SSA module is its ability to link to analyses in other modules, to provide justification that any safety or reliability targets have been met. Each effect classification in the SSA can have an assigned probability requirement associated with it. Then each failure mode can be linked to another analysis, either a Fault Tree, RBD, FMECA, Markov, or Prediction. The SSA module will then compare the probability requirement of the effect classification with the calculated probability from the other analysis to determine if the probability requirement is being met.

For example, in our aircraft overrun scenario, this effect is assigned a classification of catastrophic. The Powers That Be have decreed that catastrophic failure modes should not have a probability of greater than 1E-9 per hour. We can enter this information into the SSA module. Next, we can link the loss of deceleration capability failure mode to another analysis, perhaps a Fault Tree analysis, that calculates the probability of the failure mode's occurrence. The SSA module will then tell us if we're meeting our reliability target for the failure mode, based on the reliability analysis we've done.

While users have been building Fault Trees, RBDs, Markov models to verify a reliability target for years, the power of the System Safety Assessment module is that it can link all these analyses into a functional failure mode hierarchy. Previously, a user might have one Fault Tree to examine one critical system, then a Markov model to analyze another, with no organization or relation between the two. The power of the SSA module is that it allows users to combine all their reliability analyses into a single master project, showing all the failure modes of the system, and providing documented verification that reliability targets are being met. You can then print out reports showing the reliability targets and the reliability verified via quantitative analysis.

The other major new feature I want to talk about is User Columns in reports. User columns allow you to take the outputs from a report, then write simple code, either in Visual Basic or C# style, to create a new column in the report. Mostly, this is used to create conditional formatting, such that the font color, size, or style of a field in the report can be changed based on the value of that field, or of another field in the same row. But it can also be used to create more advanced columns, such as mathematical expressions, or logical conditions, that change the data displayed in a column. This could be used to change the units of a column, or combine multiple columns into one to, for instance, show either failure rate or characteristic life in a column, depending on whether the Rate or Weibull failure model is used.

Conditional formatting — An example of conditional formatting using User Columns that highlights first-order cut sets in red.

Conditional formatting code — The code used to generate the conditional formatting.

There are numerous other modifications and improvements that have been made in the latest release. You can read a summary of all the changes here. Customers with a current maintenance contract can upgrade for free, although you should contact us for a new license. Others can download a trial version to test it out. If you're interested in more information, or would like to upgrade, please give us a call or send us an email.

Tech Tuesday: SIL with Fault Trees

Posted on July 8, 2014 by jbelland

Howdy, folks. As Jeremy mentioned, we recently returned from Hawaii, where we were forced to go for the Probabilistic Safety Assessment & Management conference. We tried not to have too much fun in the sun between conference sessions. I also presented a paper, and I swear I had no idea where the conference was going to be when I submitted my abstract to the organizers. 😉 Anyways, the topic of my paper is great material for a Tech Tuesday post: Using Fault Trees to Analyze Safety-Instrumented Systems.

Yours truly, extolling the virtues of Fault Tree analysis

Safety-Instrumented Systems

Safety-Instrumented Systems (SIS) are designed to mitigate the risks of safety-critical processes or systems. Safety-critical systems are those that, if not properly maintained or controlled, can malfunction in such a way as to cause a significant risk to safety or another hazard. Examples of critical systems or processes are nuclear reactors, oil refineries, or even an automobile.

The SIS is designed to engage when the critical system experiences a failure. The SIS will automatically detect unsafe conditions in the critical system and prevent a hazard or restore the system to a safe state. An example of this might be an automated emergency shut-down in a reactor vessel, or even the airbag in a car. Due to their nature, SIS have stringent reliability requirements. When designing one, you need to know that it will work when required. This is where Fault Trees come into play. Using analytical FT methods, Reliability Workbench can evaluate the reliability of a SIS and help you determine its probability of failure on demand (PFD).

Take, for example, a high-integrity pressure protection system (HIPPS). This SIS is frequently see n in chemical plants and oil refineries. It is designed to prevent an over-pressurization event in a fluid line or vessel, by shutting off the input of the fluid.

The example here consists of three pressure transmitters (PT), a logic solver, and two block valves. Two-out-of-three (2oo3) logic is applied to the pressure transmitters, meaning at least two of them must register the high pressure in order for the system to trip. Only one of the two block valves must close in order to stop the fluid flow. We can build a Fault Tree to represent this logic as such:

Failure Data

If you've read one of the standards that discusses safety-instrumented systems, such as IEC 61508, 61511, or ISO 26262, you may have seen this graph, representing the four failure modes of a typical component.

λ SD: Safe, Detected λ SU: Safe, Undetected λ DD: Dangerous, Detected, λ DU: Dangerous, Undetected — λ SD: Safe, Detected
λ SU: Safe, Undetected
λ DD: Dangerous, Detected,
λ DU: Dangerous, Undetected

Safe failures are those that don't contribute to the PFD of the SIS, such as if the pressure transmitters in our HIPPS fail high. This failure won't inhibit the ability of the safety system to engage, since they are sending the signal to trip the SIS. Dangerous failures do contribute to PFD, like if the block valves fail open. Detected failures are those that are immediately known and can be corrected. Undetected failures remain hidden unless you test the component to see if it's still working. For Obvious Reasons, the dangerous, undetected failures are of the most concern.

In Reliability Workbench 11, Isograph added an IEC 61508 failure model to the program. This allows users to easily enter information for all four quadrants here; you can tell the program the overall failure rate, the dangerous failure percentage, and the diagnostic coverage for both safe and dangerous failures. The IEC 61508 failure model also allows for imperfect proof tests, so you can tell the program that some undetected failures remain undetected even after testing.

Common Cause Failures

One of the most important considerations when evaluating SIS are common cause failures (CCF). Standard probability math tells us that the probability of two random events occurring simultaneously is just the product of each individual events' probability. That is, to determine the probability that, say a coin flip lands heads and a die roll comes up 6, just multiply the probability of the coin landing heads by the probability of the die showing 6.

However, in SIS this is rarely the case due to common cause failures. CCFs basically mean that the random failures are not so random, and that components may be more likely to fail at the same time than you'd otherwise expect. For instance, the redundancy of the block valves means that you'd expect the probability of both of them to be failed to be the square of the individual probability of failure. However, due to CCFs, they are more likely to happen at the same time.

Reliability Workbench has a method of easily incorporating CCFs into the calculations. The most common method for taking these into account is called the beta factor model. With the beta factor CCF model, you can tell the program that a given percent of failures of a component are due to common causes, and all other components like it will also fail. For instance, we might say that the valves have a beta factor of 5%, meaning that 95% of their failures are random and independent, while the remaining 5% of failures of one will be due to causes that will also affect the other.

Logic Before Average

You may have heard that Fault Trees are unsuitable for solving SIS because of the way that the underlying Boolean algebra handles averaging probabilities. To an extent, what you've heard is correct. Typical Fault Tree methods can often provide optimistic results, predicting a PFD about 80% of the actual value. This is because Fault Tree methods first take an average PFD for each event, then apply the addition and multiplication laws of probability to solve for the system logic. However, SIS standards give equations that do the reverse. That is, they first apply logic, then solve for a PFD average. Since for a given function, the product of the means is not necessarily equal to the mean of the products, these two methods can produce different results.

To account for this, Reliability Workbench provides a special "logic before average" calculation method, which brings its results in line with the answers calculated using IEC 61508 methods. These proprietary calculations were first included in FaultTree+ v11, released in 2005.

Spurious Trips

Spurious trips are failures of the safety system, but in a "safe" way. That is, they are false alarms, where the SIS engages when no hazardous condition was present, due to safe failures of the components. For instance, if two of the pressure transmitters in our HIPPS were to fail high, this would send a signal to engage the SIS, even though there was no actual high pressure. While spurious trips often don't carry the same hazardous consequences that a dangerous failure does, the can be annoying and costly, because they probably involve stopping a process, which may take several hours to restart, leading to loss of production.

In some serious cases, spurious trips are more safety-critical than demand failures. Consider, for instance, the airbag on your car. If it fails to go off when needed, there's a greater chance that you'll be injured than if it had deployed. However, if it deploys when not needed, say when you're driving along at 70 mph on the highway, then it can cause you to lose control of the car and cause an accident.

One very useful feature about using Reliability Workbench to analyze SIS is the inclusion of features to easily perform spurious trip analysis. If your using the IEC 61508 failure model, then you've already entered information pertaining to safe failure rate. If you just apply some logical reversals—and again, there's a feature to automatically do this for you—then the Fault Tree can very easily be reconfigured to solve for the mean time to fail spuriously (MTTF_spurious).

PFD_avg	λ (/hour)	MTBF (hours)	RRF	Spurious trip rate (/hour)	MTTF_spurious (hours)
4.7E-3	6.193E-7	1,622,000	212.8	6.165E-6	162,200

HIPPS final analysis

There was one more section to my PSAM 12 paper, but I've already discussed it here: importance and sensitivity analysis. If you're interested in leaning more about this, Isograph offers a two-day SIS in Fault Tree training course, which covers Fault Tree basics and shows how to model complex SIS logic in the Reliability Workbench.

So there you have it; while our wives were stuck outside, basking in the sun and drinking tropical beverages from coconut shells, Jeremy and I were having a grand time at the conference, talking about how great Fault Trees are for analyzing SIS. I'm sure our wives were so jealous that they weren't able to attend the presentation.

My wife contemplates what she's missing out on by not being allowed into the conference. — My wife contemplates what she's missing out on by not being at the conference.

Tech Tuesday: Importance and Sensitivity Analysis

Posted on May 6, 2014 by jbelland

Howdy, folks! I've just returned from a training session in Houston, Texas, all about using FaultTree+ to assist in an IEC 61508 SIL analysis. I'll have a post up about that sometime later. Today, though, we'll talk about a topic hinted at in last month's Tech Tuesday: the use of Importance Analysis and Special Sensitivity Analysis.

Picture this: we've just completed an in-depth Fault Tree and risk analysis of our chemical reactor shut down system, from last week. We've determined that the point risk for our system is 4.318E-6 fatalities per year, or about one fatality per 231,600 years. That seems pretty good, but let's suppose that due to industry regulation, or corporate standards, or customer requirements, we've been assigned a reliability goal of 1E-6 fatalities per year, or one fatality per million years. This means that, in order to meet our acceptable risk target, we'd have to lower our risk by a factor of 4.318. How do we figure out the best way to do that?

results — Remember, point risk is the frequency of a consequence multiplied by the weight of the consequence.

There are two useful tools for figuring out the best way to improve reliability, either in a new design or in an existing system. Importance analysis can tell use the weak points in our system. Special sensitivity analysis will show how changing input parameters will affect the system reliability.

Importance Analysis

Importance analysis works by figuring out how much each component contributes to system unavailability. There are a few different importance measures, but probably the most useful and most used is called Fussell-Vesely importance. This importance measure tells us, basically, what percent of system failures involved each component. Another way of saying that would be the Fussell-Vesely importance tells us how much better reliability would be if the component never failed. A high Fussell-Vesely importance indicates a high contribution to system down time, meaning the component is a weak point in the system.

In our example, by performing importance analysis, we can figure out which component failures were the biggest contributors to risk.

The temperature sensor (TS1) and pressure sensor (PS1) in our safety system have the biggest F-V importance ranking, followed by the common cause failure of those two components. This makes sense because, if you remember the system, two layers of protection are dependent upon the proper functioning of the sensors.

This gives us an idea of where to get the most bang for our buck when trying to improve system reliability. Improvements to the sensors will take us a lot farther than improvements to the isolation valves (V1 & V2).

Sensitivity Analysis

Now, how much better would our valves have to be in order to meet our 1E-6 risk goal? We could use trial and error, entering different failure inputs parameters, re-running the analysis, then checking the results, or we can use Special Sensitivity Analysis. SSA is an automated method that will vary input parameters and then report back to us on how the variation affects results.

To apply sensitivity analysis to our system, we'll tell Reliability Workbench to modify the test intervals for the components in our system and record how this change affects risk. In our baseline case, the test interval is six years. We'll try a range of test intervals less than that and see which one allows us to meet the safety goal.

Test interval (months)	Safety risk
12	6.843E-7
18	9.571E-7
24	1.26E-6
36	1.899E-6
48	2.635E-6
60	3.572E-6

So, a test interval of 18 months will meet our safety goal of no more than 1 death per million years.

Sensitivity analysis can be used to adjust more than just test intervals, and examine the impact on more than just risk. For instance, how does using a component with a lower failure rate impact system unavailability? How does changing the MTTR affect risk reduction factor?

Be sure to check out the FaultTree+ module of Reliability Workbench to test out the importance analysis, sensitivity analysis, and many other features!

Tech Tuesday: Quantitative LOPA with FT/ET

Posted on April 8, 2014 by jbelland

Howdy, folks. As Jeremy has mentioned, this past Friday, April 4th, we hosted a webinar to demonstrate Isograph's FaultTree+ tool. One of the topics we discussed was how you can use the Fault Tree and Event Tree features of the tool to perform a quantitative Layer Of Protection Analysis (LOPA). This post will serve as a little summary of that meeting, for anyone who was unable to attend.

The first stage of a LOPA might be done externally to a quantitative tool like Fault Tree. The first thing you'd want to do is identify hazards, determine an acceptable risk level for those hazards, and ask what you're doing to mitigate them. This might have more in common with a Hazop study. Once you've identified your hazards and protection layers against those hazards, the next thing you might want to do is quantify it. How often will the hazard occur? How effectively will our layers of protection mitigate the risk of the hazards? Can we objectively rank these risks? This sounds like a job for Fault Tree and Event Tree analysis.

A Fault Tree can very easily be used to quantify a hazard. In fact, that's the primary usage of the method. By coupling it with an Event Tree, we can find out how well that hazard is mitigated by protection systems. If you're not familiar with it, Event Tree analysis is related to Fault Tree analysis. It uses a similar quantitative calculation. The difference is that, while Fault Trees examine the failure leading to a hazard, Event Trees examine the consequences following the hazard. Sometimes, when coupled together, they're called "bowtie events".

Continue reading "Tech Tuesday: Quantitative LOPA with FT/ET"

Tech Tuesday: FlexNet Licensing, Part 3

Posted on March 25, 2014 by jbelland

Howdy, folks. It's about time we wrapped up our three part series on the FlexNet Publisher licensing system used by Isograph's products. As we saw in part 1, the latest version of FlexNet allows for online activation and easy re-hosting of a license. In part 2, we looked at different methods of configuring a license server. Today, we'll look at one of the most common errors encountered while configuring a FlexNet server license, and how to correct it.

So, you've just purchased or upgraded Isograph's Availability Workbench, Reliability Workbench, or Hazop+ tools, and you're ready to dive in and get to work. But then when you start the program, you receive an error:

What does it mean? How do we work around it? Well, don't fret; we can help.

Breaking down the error, we see two parts to it. The first "No connection could be made to the FlexNet license server" means that the program couldn't talk to the license server. The second part "and no valid features are defined in local trusted storage." means that the program couldn't find a license on the local computer either. Combined, they mean the program can't find a license and will run in demo mode—without the ability to save or print.

There are a few likely causes for this error:

The client requires a newer version of FlexNet than what is running on the server.
The server information is not entered correctly into the client.
The FlexNet license server is not running, or is improperly configured.
A firewall, or other internet security software, is blocking the client from connecting to the server.

The first one is usually the easiest to figure out. This occurs, for instance, if you were previously running AWB 2.0 on your client machine and you upgrade to AWB 2.1.1. You might get this error message. This is because AWB 2.1.1 requires newer versions of FlexNet than what was provided in the AWB 2.0 installation. As we saw in part 2, the server version of FlexNet must be greater than or equal to the client version. If you install an upgrade on the client only, without updating the server, you'll probably get this error.

The second possible cause is sort of a dummy error, but still worth a check: if the server information is entered incorrectly into the client, you'll probably get this error. If this is the problem, don't feel bad; you're not the first person to contact Isograph support due to fat-fingering an IP address.

Item 3 can be a little trickier to diagnose. The server administrator will usually need to get involved. Sometimes this one involves looking over log files to find any mention of problem. But sometimes this one has an easy-to-fix cause. If the installation was never completed on the server, then this error will occur. For instance, sometimes the server administrator will install the FlexNet activation utility, and activate a license, but then forget to take the follow-up step of configuring the license manager (LMTOOLS or LMADMIN, as we saw in part 2). If you see the "No connection" error, make sure that you've followed the directions outlined in the installation guide for configuring the license server manager.

Item 4—firewall issues—is the one we can provide the least help on. We can tell you if a firewall is blocking connection, but we can't tell you how to reconfigure it so that it's not. For that, you'd have to refer to your firewall hardware or software manual. The way we usually tell if a firewall is at fault is by using the TELNET command. This command, which is typed into a command prompt, will attempt to connect to a computer on a given port. If a firewall is blocking the connection, it gives an error indicating so. The format of the command is:

telnet <computer name or IP> <port>

So for example:

telnet 10.0.0.250 27000

...will try to connect to the server at IP address 10.0.0.250 on port 27000. When TELNET is run from the client to try to connect to the server, on the port used by the FlexNet manager, it will help you figure out if a firewall is blocking the connection.

One more thing you can keep in mind when diagnosing this error: does it occur on all client computers or on just one? This helps narrow down the cause. If it's just one, then there's likely an issue with that particular computer. Either there's a version incompatibility or maybe the server information has been entered incorrectly into the software. If all users are experiencing the error, then the issue is most likely with the license server. Either it has been configured incorrectly or its firewall is not permitting access.

If you do encounter this error, don't feel that you have to solve it on your own. Please contact Isograph technical support: support@isograph.com, +1 949 502 5749 (North America) or +44 1925 437 002 (rest of the world). We have a lot of experience working this one out and can help you find the problem and fix it.

Well, that just about wraps up everything you wanted to know about FlexNet licensing. Join us next time for a completely different topic!

Tech Tuesday: FlexNet Licensing, Part 2

Posted on February 26, 2014 by jbelland

Howdy, folks, and welcome back for another Tech Tuesday! Last week, we talked a little about FlexNet Publisher, the copy control method used in Isograph's software. The discussion focused on basic license activation. Now, this makes sens for standalone, or node-locked, licenses. With this licensing type, the license is hosted and used on a single computer, such as a desktop computer. But for license servers, there's another piece to the puzzle.

Let me back up a bit. Isograph's software can be licensed as standalone or floating. Floating licensing allows you to share a limited number of licenses among many users. So, for instance, you could have two licenses for Reliability Workbench, but have five people who all have access to the software. This type of licensing can be more cost-effective; since licenses can be shared, the total number of licenses needed can be reduced. When one person isn't using a license, someone else can.

When Availability Workbench is started on a client machine, this is the dialog that is displayed, allowing the user to select which modules to use. It also informs users how many licenses are available.

Now, in order to set this up, the floating license must be activated on a host computer, typically a network server. This computer will then become the license server, and automatically manage the licenses. Many companies have a FlexNet license server already configured, but even in these cases, there are a few things to keep in mind when configuring a license server for Isograph's software.

Firstly, even if a FlexNet license server has already been installed and configured for other FlexNet-enabled products, you will still need to run the installer for the Isograph product, and choose to install the FlexNet license server components. For legacy products, such as AttackTree+, NAP, FaultTree+ 11, and AvSim+ 10, this is necessary in order to find out the composite host ID, which you'll remember from last time is what the license certificate is based on. For newer products, such as Availability Workbench, Reliability Workbench 11, and Hazop+ 2013, it's necessary to install the license activation utility, which is where you plug in the activation ID for online activation. For all products, installing the Isograph license server component is required to install the Isograph vendor daemon, which is one of the necessary components of FlexNet licensing.

The custom installation options for Availability Workbench 2.1. If using on a license server, you MUST choose to install the FlexNet License Server component to the local hard drive.

The second thing you'll need is the FlexNet license manager. Most server administrators who've worked with FlexNet before are familiar with LMTOOLS, the License Manager toolkit used to configure the licensing service. However, according to Flexera™, the company that develops FlexNet Publisher, LMTOOLS is at end-of-life. This means they've stopped future development on it. Their new, preferred tool for configuring a license server is called LMADMIN.

Isograph, going forward, is still supporting both LMTOOLS and LMADMIN. We recommend LMADMIN for users who are configuring a FlexNet license server for the first time. For any users still using LMTOOLS, however, I tend to recommend sticking with it, rather than upgrading. This is particularly the case since LMTOOLS and LMADMIN are incompatible with each other. A license server cannot run both at the same time. That means, if you want to upgrade to LMADMIN for one of your FlexNet-enabled products, all FlexNet-enabled products must be switched over to the new license manager.

My personal opinion is that LMADMIN is a much more feature-rich tool for configuring a license service. LMTOOLS was nice for its simplicity. No installation was required; you could simply drop the lmtools.exe onto your server, run it, and have the license service configured and running inside 30 seconds, if you knew what you were doing. LMADMIN requires a bit more setup; it has it's own installation, and it acts like a web service: you access the LMADMIN interface through a web browser. This means there's more overhead (and more opportunities for things to go wrong!) during setup, but once it's going, it's a very powerful utility for configuring license services. As I mentioned, it uses a web service interface, so you can remotely access it; you no longer have to edit license files to set things like what port numbers should be used; and the user interface provides much more information about the service, versions, and ports in use. I suppose from that, you can tell why I like it more. In my primary job providing technical support, when I'm assisting a user to configure a license server, it's much easier for me to collect information and diagnose errors if the user is on LMADMIN.

The LMADMIN vendor daemon configuration page.

Either way, both of these license manager packages are supported by Isograph and can be used to configure your floating licenses. Once the license server is configured, you're free to install the Isograph software package on any client machines. The clients will connect to the server to access a license.

One last thing to keep in mind; all these components—the license manager utility, the license manager service (LMGRD), the vendor daemon, and the client software—all have their own files and versions. Flexera™ has defined a hierarchy for version numbers:

Version of LMTOOLS must be ≥
Version of LMADMIN/LMGRD, which must be ≥
Version of the Isograph.exe vendor daemon, which must be ≥
Version of FlexNet used by the client application, which must be ≥
Version of the activation utility.

Isograph's latest products, Availability Workbench 2.1.1 and Reliability Workbench 11.1.1, both use version 11.11.1.1 of the FlexNet Publisher. What this means is that if you have an existing license server running, say, version 11.2 of LMTOOLS, you will need to upgrade the version of LMTOOLS on your license server in order to use the latest versions of those products. Isograph has download packages for version 11.11.1.1 of both LMADMIN and LMTOOLS available on our website. Please contact us to get either of these packages.

I realize I got a bit techy here, but that's the name of the column. Join me next week when we conclude this series. I'll talk a little bit about some of the more common issues that we've encountered while helping users with license servers.

Tech Tuesday: FlexNet Licensing, Part 1

Posted on February 18, 2014 by jbelland

Howdy, folks! Welcome back to another Tech Tuesday. For our US clients, I hope you enjoyed your President's Day weekend. I certainly did enjoy spending the day with my new daughter.

I'm back in the office and it's business as usual, now, so I thought I'd take this time to write about the copy protection used by Isograph.

Isograph's software uses FlexNet Publisher by Flexera Software. This is a very popular copy protection tool, used by many companies, such as Adobe, to maintain copy control. Most companies, it seems, already have a FlexNet license server set up. Some of our users also remember it when it was called FLEXlm or Flexible License Manager, and was developed by Macrovision. Either way, it's a very commonly-used tool.

Isograph has used FlexNet licensing in our products since 2004, starting with our Network Availability Program (NAP) v1.0. In 2007, with the release of Availability Workbench 1.0, we switched to what is known as FlexNet trusted storage services. Now, the latest releases of Availability Workbench, Reliability Workbench, and Hazop+ all use trusted storage services via FlexNet 11.

See, the FlexNet that most people are used to uses what is known as certificate-based licensing. In this method—used by our legacy programs, such as NAP and AttackTree+, and older versions of Reliability Workbench, FaultTree+, and AvSim+—a license certificate, typically just a text file with a long code in it, is used to activate the software. This text file is created by Isograph based on some information from the computer that the user intended to have licensed. Many software vendors use the MAC address, or network address, but Isograph's certificate licenses used the "composite host ID" which was based on several internal components of the computer, including the hard disk and network card. This way, the license file would only activate a single computer—the one it was created for. To activate the computer, the license file just had to be placed in the program's directory.

A typical license file. This identifies the computer for which it was created (the "COMPOSITE=" number), the program it will activate ("FTP" = FaultTree+) the version (11.0) and the expiry date (16-Mar-2014).

The drawback to certificate-based licensing is that it's difficult to move the license; it's generated for a specific machine, so to move the software to another machine, you had to contact Isograph for another license. And because this could be abused, we typically asked for a written statement saying that you would delete your old license when you received the new one. We also ran into a few issues in some cases, where changing the computer's components would result in the license no longer working. For instance, switching from a wireless to a wired network, or plugging a laptop into a docking station would fool the FlexNet service into thinking that it was now on a different computer, one that had not been licensed.

But as I mentioned, starting in 2007, we moved to FlexNet trusted storage licensing. In this method, rather than you giving us an identifying number from your computer, we simply give you a code called an activation ID. To activate your license, you simply copy and paste this code into the software, and it will connect to our license server over the internet and activate your license. Once this initial connection and activation is complete, no further contact with our servers is needed.

The license activation screen. Just plug in the activation ID we sent to you, press activate, and—Bob's your uncle—the software is licensed. Be sure to hang on to the activation ID, as you'll need it if you want to move the license to another computer.

The advantages to this are many; you don't need to wait on us to activate or move a license. If you decide you'd rather move the license to another computer, you can do it yourself very simply. It also works well with upgrades. Previously, if you needed an upgrade license, we would ask for written confirmation that you'd deleted your old licenses. Now, you can just return your licenses over the internet, and we'll be able to see that you've done that. In fact, with the latest version of FlexNet publisher, upgrades can be done automatically. We'll issue you an upgrade activation ID and when you activate it, your previous-version licenses will be automatically returned.

For users without an internet connection, which is common with servers or secure computers, trusted storage licenses can also be activated via request and response files. Basically, the same information that's sent via a web connection can also be sent via email. You'll enter the activation ID into the software, and generate a requestXML file, which you'll email to us. We use this file to create a responseXML file which we send back to you. You'll process this response file and the license is activated. Licenses can also be returned and re-hosted using this method.

The FlexNet Ops console. From here, we can create an activation ID for you, process a request file to generate a response file, and view the license activation history. We can only tell the date and time that a license was activated or returned, and if it was activated via the internet or request/response files. We can't see any information about the computer that activated it, such as IP address, host name, or your passwords.

And for users with highly-secure computers, from which you can't remove any files—this is common for top secret government or military contractors—we can still fall back on certificate-based licenses, where you'll only need to send us the MAC address.

Next week, I'll talk more about FlexNet license servers, the newest version of the FlexNet publisher server software, and the differences between LMTOOLS and LMADMIN for configuring the server.

Author: jbelland

Tech Tuesday: Network Availability Prediction 2.0

Tech Tuesday: Reliability Workbench 12

Tech Tuesday: SIL with Fault Trees

Tech Tuesday: Importance and Sensitivity Analysis

Tech Tuesday: Quantitative LOPA with FT/ET

Tech Tuesday: FlexNet Licensing, Part 3

Tech Tuesday: FlexNet Licensing, Part 2

Tech Tuesday: FlexNet Licensing, Part 1

Let's Keep In Touch!

Isograph

Our Products

Company

Useful Links

Contact Us