juare97 freelance – blog baru


untuk mengisi waktu saat fieldbreak dan mencoba membuka lapangan pekerjaan baru, juare97 coba untuk menawarkan program training atau pekerjaan freelance dengan harga yang kompetitive.

Silahkan mengunjungi blog berikut:


Kedepan, isi penawaran training diatas akan ditambahkan.
Rencananya juare97 juga akan menggandeng rekan-rekan lain yang expert dalam bidang electrical dan mechanical (rotating).

Do’a kan semoga lancar yah… 🙂
Semoga bisa membuka lapangan pekerjaan baru juga.


Pakai Moxa NPort 5110 untuk koneksi ke PLC di remote area


sekedar sharing…

bbrp waktu yang lalu ada pekerjaan pengecekan komunikasi PLC Mocrologix 1200 diremote area.

Catatan: gbr diambil dari The Automation Blog.

Kami sudah bbrp kali kesana untuk troubleshooting dan pengecekan tetapi belum ketemu juga.

Akhirnya kami ubah alur datanya.


PLC 1 (serial) – MOXA (Serial to Ethernet, Pair Slave Mode) – MOXA (Ethernet to Serial, Pair Master Mode) – Modem Switching Serial (ada PLC ke-3 yang masuk ke sini) – MOXA (Serial to Ethernet) – MOXA (Ethernet to Serial) – PLC 2 (Serial, Master, yang ambil data PLC1) – data disebar ke sistem SCADA via DH+ dll.

Kami ubah menjadi:

PLC 1 (serial) – MOXA (Serial to Ethernet, Real COM Mode) -HMI WW Intouch (copy data tag ke tag lain) – MOXA (Ethernet to Serial), Real COM Mode) – ABKF2 (DH+ to DF1/Serial) – PLC 2 – data disebar ke sistem SCADA via DH+ dll.

Alhamdulillah sekarang sudah bisa monitor dan lebih mudah troubleshootingnya karena bisa dilihat langsung setting MOXA nya dan PLC nya.

Catatan: gambar diambil dari web MOXA

Artikel PLC / HMI lainnya:

Sebaik-baik manusia adalah yang paling bermanfaat bagi manusia yang lain.

Ditulis dalam PLC-HMI. 4 Comments »

sharing bacaan: Determine safety integrity level for a process application

sharing bacaan: menentukan safety integrity level (SIL) untuk aplikasi process.

sumber: http://www.controleng.com/single-article/determine-safety-integrity-level-for-a-process-application/42a818a756389bbaaca1e1a9233c640a.html

sisanya terjemahin sendiri aja yah … 🙂

Determine safety integrity level for a process application.

Safety instrumented systems (SIS) are installed in process plants to mitigate process hazards and they must be assigned a target safety integrity level (SIL) during the process to determine what needs to be done next.


Safety instrumented systems (SIS) are installed in process plants to mitigate process hazards by taking the process to a “safe state” when predetermined set points have been exceeded or when safe operating conditions have been transgressed.

The SIS is one protection layer in a multi-layered safety approach since no single safety measure alone can eliminate risk. A layer of protection analysis (LOPA) is a method whereby all known process hazards and all known layers of protection are closely scrutinized. For each process hazard where the LOPA study concludes that existing protection cannot reduce risk to an acceptable or tolerable level, a SIS is required. Not all process hazards will require the use of a SIS. Each hazard that requires the use of an SIS must be assigned a target safety integrity level (SIL).

What are SIL levels?

SILs comes from two voluntary standards used by plant owners/operators to quantify safety performance requirements for hazardous operations:

  • IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems
  • IEC 61511: Safety Instrumented Systems for the Process Industry Sector.

As defined in the IEC standards, there are four SIL Levels (1-4). A higher SIL Level means a greater process hazard and a higher level of protection required from the SIS. SIL Level is a function of hazard frequency and hazard severity. Hazards that can occur more frequently or that have more severe consequences will have higher SIL Levels.

To determine SIL Levels of process hazards, it is helpful to understand the safety lifecycle.

Safety lifecycle

The IEC standards define a concept known as the safety lifecycle, which provides a repeatable framework whereby all process hazards are identified and analyzed to understand which hazards require the use of a SIS for mitigation. By design, this is a cyclical process. Any changes in process design, operating conditions, or equipment requires cycling back to the beginning to ensure any changes are properly implemented.

Example of a safety lifecycle model. Courtesy: Cross Company, adapted from IEC 61511

There are many steps to follow to determine SIL Level and it starts with performing a process hazard analysis (PHA).

A PHA is a systematic assessment of all potential hazards associated with an industrial process. It is necessary to analyze all potential causes and consequences of:

  • Fires
  • Explosions
  • Releases of toxic, hazardous, or flammable materials, etc.

Focus on anything that might impact the process including:

  • Equipment failures
  • Instrumentation failures or calibration issues
  • Loss of utilities (power, cooling water, instrument air, etc.)
  • Human errors or actions
  • External factors such as storms or earthquakes.

Both the frequency and severity of each process hazard must be analyzed:

  • How often could it happen? Tank spills could happen any time there’s a manual fill operation (multiple times a year)
  • How severe is the result? Localized damage, fire, explosion, toxic gas release, death.

Core to the PHA analysis is the fact that things can and do go wrong. Forget whether if it will happen and instead consider when it will happen. Each identified hazard is assigned an “acceptable” frequency. You cannot assume a hazard will “never” happen.

  • A hazard which results in simple First Aid could be considered “acceptable” if it could happen only once a year
  • An explosion and fire due to a tank rupture could have an “acceptable” frequency of once in 10,000 years.

The end result of the PHA is a list of all possible process hazards with each one assigned an acceptable frequency of occurrence. With the PHA complete, the next step in the safety lifecycle is the layer of protection analysis.

No single safety measure alone can eliminate risk. For this reason, an effective safety system must consist of protective layers. This way if one protection layer fails, successive layers will take the process to a safe state. As the number of protection layers and their reliabilities increase, the safety of the overall process increases. It is important to understand that each layer must function independently from the others in case one or more layers fails.

Some specific examples of protection layers include:

  • Fire suppression systems
  • Leak containment systems (dikes or double walls)
  • Pressure relief valves
  • Gas detection/warning systems.

For every process hazard identified in the PHA:

  • List all available non-SIS safety measures
  • Assign each layer its own hazard risk reduction factor
  • Calculate an effective hazard frequency with protection layers applied.

Example: A tank fill operation that happens 250 times per year – “could” experience an overfill event 250 times per year.

  • A protection layer in the form of a proper vent/drain system could reduce the danger by a factor of 100 (risk reduction factor)
  • The hazard resulting from tank overfill would have an effective frequency of 250/100 = 2.5 times per year.

After the effective hazard frequency of each hazard is known, the key question to ask is: “With non-SIS protection layers applied, is the effective frequency lower than the acceptable frequency?”

Once all process hazards are identified and protection layers assigned, if the PHA/LOPA study concludes that existing protection cannot reduce risk to an acceptable or tolerable level, a safety instrumented system (SIS) will be required. Not every process hazard, however, actually requires the use of a SIS.

Safety instrumented systems and functions

The purpose of a SIS is to take a process to a “safe state” when predetermined set points have been exceeded or when safe operating conditions have been transgressed.

The role of the SIS is to reduce risk by implementing safety instrumented functions (SIFs). Two example SIFs include:

  • Hazard: Tank overfill. SIF: The SIS stops the fill pumps at a predetermined safe level
  • Hazard: High temperature. SIF: The SIS opens a relay to cut power to a heater circuit at a predetermined safe temperature.

In any case, an SIF is a safety function implemented by the SIS to achieve or maintain a safe state. An SIF’s sensors, logic solver, and final elements act in concert to detect a hazard and bring the process to a safe state.

Each SIF serves as a protection layer to bring the effective hazard frequency down below the acceptable hazard frequency. To do this, each SIF must have a minimum risk reduction factor.

Target SIL level of the SIF

With the tank overfill example, it was determined that after applying non-SIS protection layers there was an effective frequency of 2.5 times per year. If the acceptable hazard frequency is once in 10 years, then the SIF must have a risk reduction factor (RRF) of at least 25.

  • Minimum RRF of SIF = Effective frequency w/o SIS / Acceptable frequency = 2.5/0.1 = 25.
  • The minimum required RRF of each SIF is used to determine the target SIL level of the SIF.

Target SIL Level is directly determined from the required RRF by using the table in Figure 3. Note the relationship between SIL Level and RRF. SIL1 has a minimum RRF of 101, SIL2 has a minimum RRF of 102, and so on.

SIL Required Risk Reduction Factor (RRF)
1 10 to 100 (101 to 102)
2 100 to 1,000 (102 to 103)
3 1,000 to 10,000 (103 to 104)
4 10,000 to 100,000 (104 to 105)

For the tank overfill example, the minimum RRF is 25, the target SIL level of the SIF is SIL1 and this is, therefore, an SIL1 hazard.

For each hazard identified by the PHA and LOPA that requires an SIF, a target SIL level is assigned using the same methodology. Note that it is likely you will have various target SIL levels. The next step in the process is to design a SIS capable of implementing the required SIFs and reaching the target SIL levels.

Achievable SIL level of the SIF

The SIS is a system comprised of numerous components such as:

  • Sensors for signal input
  • Input signal interfacing and processing
  • Logic solver with power and communications
  • Output signal processing, interfacing, and power
  • Actuators (valves, switching devices) for final control function.

An example SIF where the SIS de-energizes a relay to open a heater circuit upon high temperature could have any or all of the following loop components:

  • Thermocouple
  • Transmitter
  • Input signal conditioner or barrier
  • Analog input card
  • Communication card(s)
  • CPU
  • Discrete output card
  • Output signal conditioner or barrier
  • Heater circuit relay.

One must assume that a hazard will occur at some point. You cannot assume a hazard will “never” happen. Similarly, one must assume that any of the components of the SIF could fail to act upon demand.

One very common failure would be an isolation valve that remains open under normal process conditions. If this valve is required to close to achieve a particular SIF, it is possible that the valve could stick open and not close upon demand. For this reason, one must know the failure probability the SIF.

The overall failure probability of a given SIF is determined by performing SIL calculations (SIL calcs). SIL calcs are somewhat complex and are outside the scope of this article but essentially, the process is to gather failure rate data for the SIF components and account for factors such as test frequency, redundancy, voting arrangements, etc. The end result is that for each SIF, you end up with an overall probability of failure on demand (PFD).

Failure rate data for the numerous pieces of equipment that make up SIF loops are published by the equipment manufacturers. Companies frequently contract with consultants to determine failure rate values.

It is failure rate data that is required as an input to perform SIL calcs for an SIF, not SIL Level data. There is no such thing as an SIL-rated device. We don’t buy SIL-rated transmitters or SIL-rated control systems.

Once the PFD of the SIF is known, then its RRF is simply the inverse of PFD (RRF = 1/PFD). You can then compare the SIF’s RRF to the minimum required RRF. If the SIF’s RRF is greater than the minimum RRF, then the SIF is sufficient to reduce the overall hazard level below the acceptable level.

Returning to our tank overfill example, let’s assume the SIL calcs prove the SIF has an RRF of 300. Since this is greater than 25, then the SIF is sufficient. If the SIL calc had found an RRF of less than 25, then changing or rearranging the SIF components would be necessary. One way to increase the RRF is to install redundant transmitters in a voting arrangement or to purchase transmitters with lower published failure rates.

The relationship between SIL level, RRF, and PFD is demonstrated below.

1 1 in 10 – 1 in 100 10 to 100
2 1 in 100 – 1 in 1,000 100 to 1,000
3 1 in 1,000 – 1 in 10,000 1,000 to 10,000
4 1 in 10,000 – 1 in 100,000 10,000 to 100,000

Going back to the tank fill example, there was a minimum RRF of 25 (SIL1) with an SIF RRF of 300. The achievable SIL level of the SIF is SIL2. This means there’s an SIL2-capable SIF being used to protect an SIL1 hazard. This is perfectly acceptable and is not unusual.

David Yoset is a project manager with Cross Company. This article originally appeared on Cross Company’s Integrated Systems blog. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, cvavra@cfemedia.com.

Cross Company is a CSIA member as of 4/20/2017.

Ditulis dalam SIS. 2 Comments »

sharing bacaan: Four things to remember about DCS migration

sekedar sharing bacaan.

diambil dari:


Four things to remember about DCS migration

Whether it’s a refinery, chemical plant, or other process-related facility, the primary control system must operate efficiently, safely, and economically. If it doesn’t, perhaps it’s time for an upgrade.

Plant and operations managers don’t wake up one day and realize their distributed control systems (DCSs) and programmable logic controllers (PLCs) may be approaching obsolescence and a plan of action should be formulated. Unfortunately, the realization that a process plant’s control platform is becoming ineffective typically comes too late, speaking from practical and economical perspectives.

When that realization comes, it’s time to do some type of control system upgrade. Whether piece by piece replacement over time or a full rip-and-replace migration is in order, there are four things to remember about DCS migration:

  • Decide that DCS migration is necessary
  • Decide the appropriate justification
  • Plan the migration path
  • Implement the migration plan.

The necessity of migration

John Rudolph, vice president of Lifecycle Solutions and Services at Honeywell Process Solutions, wrote in an article that appeared in the July 2016 issue of Control Engineering titled “Surviving a control system migration project”:

“In its 2015 report, ‘Distributed Control Systems Worldwide Outlook,’ the ARC Advisory Group estimated that $65 billion worth of installed process automation systems in the world today are nearing the end of their useful lifecycles, which, in many cases, can exceed 25 years. Many of these systems—as much as $12 billion worth—are some of the original distributed control systems (DCSs) installed in the late 1970s. Ironically, many manufacturers treat their business systems and email servers very differently than their process control systems. Companies make a concerted effort to keep IT infrastructure current. The same level of emphasis is not yet common practice for plant automation.”

Even though a legacy control system may still work well after 30 years or even longer doesn’t mean that it is operating efficiently, reliably, safely, or cost-effectively.

Jeff Morton, a sales manager at Cross Company Integrated Systems Group, wrote in an article that appeared in the January 2017 issue of Control Engineering titled “Six action items for an aging DCS/PLC”: “Budgets are always a constraint and capital expenditures may be tight, especially for full distributed control system (DCS) or programmable logic controller (PLC) replacements, which are often multi-million dollar investments.

“That investment, though, is nothing compared to the cost if the production facility went down and could not recover for a week or more. What’s even more concerning than that is there are many facilities that are unprepared for system failure or obsolescence, which can have catastrophic consequences. Operations, facility, or engineering managers need to begin preparing for migration of your control system from a legacy system to current and supported architectures.”

DCS migration justification

According to Rudolph, when it comes to keeping automation technology up to date, proactive is the new normal. Companies that migrate to a newer, more effective control system gain a key advantage over competitors that wait for assets to reach end of life. The “doing nothing” option is no longer viable.

In a Control Engineering article titled “Distributed control system upgrades for process control systems,” Aneel Shahzad Baig, senior project manager at Intech Process Automation, wrote that reasons to upgrade a DCS include:

  • End of life
  • End of support
  • Lack of knowledge or skilled resources to support legacy systems
  • Performance issues
  • Lack of openness for expansion or integration with newer systems
  • Lack of features required for enhancing the control philosophies
  • Maintenance costs.

Emerson’s Laurie Ben and Aaron Crews offer additional reasons for a control system modernization project in their article, “Using automation modernization for business success,” which appears in the April 2017 issue of AppliedAutomation.

  • Expense—the automation system is expensive to keep healthy.
  • Decreasing value—the automation system has few tools and technologies to help meet current business needs and market pressures.

Laurie Ben is the director of global modernization business development at Emerson. Aaron Crews is the director of global modernization solutions at Emerson.

Plan the migration path

Although the initial decision to upgrade and justifying the migration project are necessary, the actual project planning is probably the most point to consider so far. There are so many decisions to which the classic engineering answer is applicable: “It depends.”

Rudolph suggests the following upgrade possibilities for a legacy DCS: Upgrade possibilities for a legacy DCS include:

  • Technology refresh involving replacement of legacy electronics
  • Technology upgrades involving replacement of existing equipment
  • Intellectual property upgrades transitioning to more advanced technology.

Typical migration alternatives, according to Rudolph, can include:

  • Moving control to the current hardware to preserve the installed inputs/outputs (I/O) and all of the existing engineering
  • Moving control to the current hardware to preserve the installed I/O and re-engineering the current control software
  • Moving control to the current hardware, upgrading to new I/O, and re-engineering the current control software
  • Removing the control system—including I/O—and completely re-engineering all of the control software.

Ben and Crews suggest three behaviors for achieving success in a DCS modernization:

  1. Begin with the end in mind
  2. Actively manage project risk
  3. Use a forward-engineering philosophy.

When planning any kind of DCS migration, one must not leave out the training aspect. “A DCS migration, particularly one in which a new platform is introduced, requires much thought and can unleash a variety of problems if not executed well. Training is a significant issue and should be approached carefully,” wrote Peter Welander, contributing content specialist for Control Engineering, in an article titled “DCS migrations: Opportunity for improvement, or operational disaster” in the July 2016 issue of the magazine.

Implement the migration plan

There are many things to consider when faced with an aging DCS, but they can be summed up into these four things to remember: necessity, justification, plan, and implementation. By the same token, there are many challenges to consider as well.

“If properly planned and implemented, control system migrations enable industrial organizations to migrate legacy control platforms at their own pace, allowing new controllers to be added at any time and integrated with existing equipment,” Rudolph said. “A well-executed strategy to address technology obsolescence delivers significant operational and business benefits through seamless integration of new and existing automation assets.”

Jack Smith is content manager, CFE Media, Control Engineering, jsmith@cfemedia.com.


Key concepts

  • Even though a legacy control system may still work well after 30 years or even longer doesn’t mean that it is operating efficiently, reliably, safely, or cost-effectively.
  • Companies that migrate to a newer, more effective control system gain a key advantage over competitors that wait for assets to reach end of life.
  • Although the initial decision to upgrade and justifying the migration project are necessary, the actual project planning is probably the most point to consider so far.

Consider this

How old is the distributed control system (DCS) running your critical process? If it is approaching 30 years old, do you have a migration plan in place?

Ditulis dalam DCS. Leave a Comment »

Sharing berita: Emerson mengakuisisi Pentair Valves & Controls

[sharing bacaan] kalibrasi pressure transmitter oleh Endress+Hauser

sharing bacaan dari control global …

Basics of calibrating pressure transmitters
This solution brief from Endress+Hauser details pressure transmitter best practice guidelines, and describes the basics of calibrating pressure transmitters for maximum performance.

⇒ Read the solution brief now

kalau di klik linknya maka terbuka ke sini…


Basics of Calibrating Pressure Transmitters

Know the basics of calibrating pressure transmitters for maximum performance

Pressure transmitters used in the process industries are very durable and reliable instruments. Even so, they still require periodic maintenance and calibration to ensure optimal performance. As with most things in life, there is no “one size fits all” answer. However, there are simple best-practice guidelines, which can be modified to fit specific applications. This article helps answer the basic questions facing process plant personnel with regard to calibration.

Calibrating confusion

Many questions and concerns arise when it comes time to calibrate instruments. A few common questions are:

  • Are we calibrating our transmitters too often, resulting in excessive downtime and unnecessary maintenance expense?
  • Are we calibrating our transmitters too infrequently, resulting in quality issues and possible loss of product?
  • Are we calibrating our transmitters correctly?
  • How do you calibrate and who should do the calibrating?

Click the button below for answers and more calibration details!

Silahkan di download link diatas untuk membaca detailnya ….
Saya kutip Summarynya sbb:
The “correct” calibration cycle for a pressure transmitter will depend on the purpose of the calibration and the application. The same pressure transmitters employed in different operating units or processes at the same plant may require different calibration intervals.

Even more important than the calibration interval of the instrument are:
• Establishing correct and realistic MPEs
• Following correct calibration procedures
• The training of the person performing the calibration
• Proper documentation of calibration results.

Following these guidelines and using judgment based on actual plant operation conditions will help establish proper calibration practices, saving money while maintaining acceptable performance.