Functional Safety

Should I consider residual failures in SIL calculations?

It is important to realize that the residual failures are included in the safe undetected failure category according to AS IEC 61508. Note that These failures on their own will not affect system reliability or safety, and should not be included in spurious trip calculations.

What is difference between SIS, SIF and SIL?

Safety instrumented system (SIS) is designed to respond to conditions in the plant which may be hazardous in themselves or, if no action was taken, could eventually give rise to a hazard,  and to generate the correct outputs to mitigate the hazardous consequences or prevent the hazard. An SIS is composed of any combination of sensor(s), logic solver(s) and final element(s). A SIS is used to implement one or more safety instrumented functions (SIF) commonly known as an instrument loop. Safety integrity level (SIL) is a risk reduction factor assigned to the SIF, determined by considering other independent production layers to achieve required risk reduction.

Is safety integrity level (SIL) being defined just to reduce the risks of fatality and injury?

The hazardous consequences could be fatality, injury, asset or environment considerations. For a safety instrumented function (SIF), which is implemented in SIS, an integrity level must be determined for safety considerations; fatality and injury (SIL), an integrity level must be determined for asset consideration (AIL) if applicable and finally an integrity level must be determined for environment considerations (EIL) if applicable. At the end the highest required integrity level shall be implemented for this specific SIF.

What does fault tolerant mean for a component?

Hardware fault tolerance is the ability of a component or subsystem to continue to be able to undertake the required safety instrumented function in the present of one or more dangerous faults in hardware. It is important to note that the hardware fault tolerance requirements represent the minimum component or subsystem redundancy. Refer to AS IEC 61151 for the minimum hardware fault tolerance requirements. Note that a hardware fault tolerance of N means that N+1 faults could cause a loss of the safety function. If the equipment is proofed in use in the number of less than required by standard to meet hardware fault tolerance condition, then no need to be worry about standard requirements (refer to IEC 61511).

When a redundant structure must be used in a safety instrumented system (SIS)?

Depending on the application, component failure rate and proof-testing interval, additional redundancy may be required to satisfy SIL of the SIF.

Is there any restriction for hardware implementation of interface between SIS and DCS?

The communication interface between DCS/SIS shall be suitable for communication between devices referred to different electrical ground potentials. An alternate medium (for example fibre optics) may be required, AS IEC 61511.

Is it acceptable to force SIS inputs or outputs?

Based on AS IEC 61511 forcing of inputs and outputs in SIS shall not be used as a part of

  • application software
  • Operating procedures
  • Maintenance, except as noted below
  • Forcing of inputs and outputs without taking the SIS out of service shall not be allowed unless supplemented by procedures and access security. Any such forcing shall be announced or set off on alarm as appropriate.

What if a new hazard be identified during SIS operation?

Additional functional safety assessment activities may need to be introduced as new hazards are identified, after modification and at periodic intervals during operation.

Which information must be given in safety requirements specification (SRS)?

The requirements to design the SIS shall include

  • A definition of the safe state of the process for each identified safety instrumented function.
  • Requirements to being able to manually bring the process to a safe state.
  • The failure modes and response of the SIS on the detection of faults should be defined.
  • The specified action (fault reaction) required to achieve or maintain a safe state.
  • The safety integrity level and mode of operation (demand/continuous) for each safety instrumented function.
  • Determine the common cause
  • Any specific requirements related to the response time for each safety instrumented function
  • Requirements for resetting the SIS after a shutdown.
  • Any specific requirements related to the procedures for starting up and restarting the SIS.
  • Requirements relating to energize or de-energize to trip.
  • If there is a target frequency for nuisance trips, this also should be specified as part of the safety requirements specification (SF reliability).
  • The interface between the SIS and the operator need to be fully described.
  • Requirement for proof-testing intervals.
  • There may be need for bypasses to allow the SIS to be tested and maintained.

Is there any restriction for wiring of field devices in AS IEC 61511?

Each individual field device shall have its own dedicated wiring to the system input/output, except in the following cases.

  • Multiple discrete sensors are connected in series to a single input and the sensors all monitor the same process condition (for example motor overloads).
  • Multiple final elements are connected to a single output.
  • A digital bus communication with overall safety performance that meets the integrity requirements of the SIF it services.

Is it acceptable to use Field Bus in SIS wiring?

ANSI ISA 84.01-1996

Each individual field device shall have its own dedicated wiring to the system IO. Field Bus is not allowed.

IEC 61511 / ANSI ISA 84.01-2004

Each field device shall have its own dedicated wiring.

Exception: A digital bus with overall safety performance that meets the integrity requirements of the SIF it services (11.6.3).

Is it acceptable to implement safety instrumented functions of different safety integrity levels in application software?

Where the application software is to implement safety instrumented functions of different safety integrity levels or non-safety functions, then all of the software shall be treated as belonging to the highest safety integrity level, unless independence between the safety instrumented functions of the different safety integrity levels can be shown in the design. The justification for independence shall be documented. Whether independence is claimed or not, the intended SIL of each SIF shall be identified. IEC 61511-2 provides guidance on how to design and develop the application software when both safety and non-safety instrumented functions or when SIF of different SIL are to be implemented in SIS.

Ideally, the interactions between the application code (SIF and non-safety) and all variables (SIF and non-safety) should be checked automatically by the application development software. If this feature is not available, the application software developer and other persons performing verification of the application software should check all application code and associated variables for conformance to the separation rules given above.

What should be included in application program documentation?

As a minimum, the following information shall be contained in the application program documentation or related documentation.

  • Legal entity (for example company. Author(s))
  • Description
  • Traceability to application functional requirements
  • Logic conventions used
  • Standard library functions used
  • Inputs and outputs
  • Configuration management including a history of changes

What is difference between surveillance and audit activities in evaluating the performance of a safety instrumented system?

A distinction needs to be made between “surveillance and checking” and audit activities. Surveillance and checking focuses on evaluating the performance of specific lifecycle activities (for example supervisor checking completion of maintenance activity prior to the component being returned to service). In contrast, audit activities are more comprehensive and focus on overall implementation of safety instrumented systems concerning the safety lifecycles. An audit would include determination as to whether the surveillance and checking program is carried out.

Audits and inspections may be carried out by a company’s/site’s/plant’s/project’s own staff (for example, self-audit) or by independent persons (for example, corporate auditors, quality assurance department, regulators, customers or third parties).

Management at the various levels may want to apply the relevant type of audit to gain information on the effectiveness of the implementation of their safety instrumented systems. Information from audits could be used to identify the procedures that have not been properly applied, leading to improved implementation. Minimum one audit is mandated by standard.

What is the general approach to determine the need for a SIS and its associated SIL?

In order to determine the need for a SIS and its associated SIL, it is important to consider what other protection layers exist (or need to exist) and how much protection they provide. After considering the other protection layers, a determination then should be made on the need for a SIS protection layer. If a SIS protection layer is needed, a determination should then be made on the SIL for the safety instrumented function(s) of the SIS. In practice, safety functions are in many cases only allocated to safety instrumented systems where there are problems in using inherently safe designs or other technology systems.

When a safety function is allocated to a safety instrumented function, it will be necessary to consider whether the application is in demand or in continuous mode. The majority of applications in the process sector operate in demand mode where demands are infrequent. In such cases, table 3 in IEC 61511-1 is the appropriate measure to use.

There are some applications where demands are frequent (for example, greater than one per year) and it is more appropriate to consider the application as continuous mode because the probability of dangerous failure will be primarily determined by the failure rate of the SIS. In such cases, table 4 in IEC 61511-1 is the appropriate measure to apply. Continuous mode applications where failure will result in an immediate hazard are rare. Burner or turbine speed control may be continuous mode application if protection systems are insufficient for all failure modes of the control system.

IEC 61511-1 limits the dangerous failure rate, in relation to a particular hazard, that can be claimed to 10-5 per hour unless the system is implemented according to the requirements of this standard. The reason for the limit is that if a lower dangerous failure rate is claimed, it would be in the range of failure rates within table 4 of IEC 61511-1. The limit insures that high levels of confidence are not placed on systems that do not meet the requirements of IEC 61511-1.

Which information needs to be documented in HAZOP study?

In summary, the hazard and risk analysis should consider the following:

  • Each determined hazardous event and the event sequences that contribute to it.
  • The consequence and likelihood of the event sequences with which each hazardous event is associated; these may be expressed quantitatively or qualitatively.
  • The necessary risk reduction for each hazardous event.
  • The measure taken to reduce or remove hazards and risks.
  • The assumption made during the analysis of the risks, including the estimated demand rates and equipment failure rates; any credit taken for operational constraints or human intervention should be detailed.
  • References to key information which relates to the safety-related systems at each SIS lifecycle phase (for example verification and validation activities).

The information and results which constitute the hazard and risk analysis should be documented.

Is it true to assign a SIL to a component?

The targets for average probability of failure on demand or frequency of dangerous failures per hour apply to the safety instrumented function, not to individual components or subsystems. A component or subsystem (for example, sensor, logic solver, and final element) cannot have a SIL assigned to it outside its use in specific SIF. However, it can have an independent maximum SIL capability claim.

Is it acceptable to use normal DCS for safety instrumented system?

Risk reduction of less than 10 may be claimed from instrumented systems without the need to comply with IEC 61511-1. This allows the DCS to be used for some risk reduction without the need to implement such systems to the requirements of IEC 61511-1. Any claim made should be justified by consideration of the integrity of the DCS (determined by reliability analysis or performance data) and the procedures used for configuration, modification and operation and maintenance. When allocating risk reduction to functions in the DCS, it is important to insure that access security and change managements are provided. The risk reduction that can be claimed for the DCS function is also determined by the degree of independence between the DCS function and the initiating cause.

How to reduce the effect of common cause?

The common cause can be reduced by changing the design of the safety instrumented system or the basic process control system. Diversity of design and physical separation are two effective methods of reducing the likelihood of common cause failures. This is usually the preferred approach.

It should be noted that any sensors or actuators which are shared by the DCS and SIS are very likely to introduce common cause failure.

The effect of common cause, common mode and dependant failures may be dominant for safety integrity levels of 3 or higher. The following should be considered:

  • Independence between protection layers
  • Diversity between protection layers. Some diversity can be achieved by using equipment from different manufacturers but if SIS and DCS sensors are connected to the process using the same type of hook up, then the diversity may be of limited value.
  • Physical separation between different protection layers.

Why separation of DCS and SIS is strongly recommended?

Based on AS IEC 61511, the SIS is normally separated from the DCS for the following reasons:

  • To reduce the effects of the DCS on the SIS, especially when they share common equipment.
  • To retain flexibility for changes, maintenance, testing and documentation relating to the DCS.

Separation between the SIS and the DCS may use identical or divers separation. Identical separation would mean using the same technology for both the DCS and SIS whereas separation would mean using different technologies from the same or different manufacturer.

Compared to the identical separation, which helps against random failures, diverse separation offers the additional benefit of reducing the probability of systematic faults and of reducing common cause failures.

Identical separation between SIS and DCS may be acceptable for SIL 1, SIL 2 and SIL 3 applications although the sources and effects of common cause failures should be considered and their likelihood reduced.

Diverse separation offers the additional benefits of reducing the probability of systematic failures (a factor especially important in SIL 3 and SIL 4 applications) and reducing common cause failures. There are four areas where separation between the SIS and DCS is generally provided.

Field sensors

Where a single sensor is used for both a DCS and SIS function, the requirements of IEC 61511-1 will normally only be satisfied if the sensor diagnostics can reduce the dangerous failure rate sufficiently and the SIS is capable of placing the process in the safe state within the required time. In practice this is difficult to achieve even for SIL1 applications. For a SIL 2, SIL 3 and SIL 4 safety instrumented function, separate SIS sensors with identical or diverse redundancy will normally be needed to meet the required safety integrity. When a single separate SIS sensor is used, there may be advantages to repeating the signal to the DCS through suitable isolators. Such an arrangement can lead to improved diagnostic coverage by allowing signal comparison between DCS and SIS sensors.

Note: 2oo3 sensor configuration can be shared between DCS and SIS.

Final elements

In the same way as for the sensors, using a single valve for both the DCS and SIS requires further review and analysis. In general, a single valve used for both the SIS and DCS is not recommended if the failure of the valve would place a demand on the SIS. Where a single valve is used by both the DCS and SIS, the requirements of IEC 61551-1 will normally be only satisfied if the valve diagnostics can reduce the dangerous failure rate sufficiently and the SIS is capable of placing the process in a safe state within the required time. In practice, this is difficult to achieve even for SIL 1 applications. For a SIL 2, SIL3 or SIL 4 safety instrumented functions, separate SIS valves with identical or diverse redundancy will normally be needed to meet the requited safety integrity. Where a single valve is used for both DCS and SIS functions, the design should ensure that the SIS action overrides the DCS action.

Logic solvers

Wiring

On energize to trip systems, the DCS and relevant field device wiring is normally separated from wiring to the SIS and its relevant field devices because of the possibility of accidentally deactivating the safety function without noticing it. Typical guidelines for these types of systems include installing separate multi-conductor cables and junction boxes dedicated to the SIS and DCS. Where the wiring is not separated, the use of good labelling and maintenance procedures to minimize the potential of errors caused during maintenance resulting in deactivation of the SIS are suggested. Note energize to trip refers to SIF circuits where the outputs and devices are de-energized under the normal operation. Application of power (for example electricity or air) causes a trip action.

The cable support system (for example cable trays or conduit), may be common for both de-energize to trip and energize to trip systems, unless separation is required for other reasons (for example, electromagnetic interference). On energize to trip systems, consideration may be given to adding fire protection to the cable trays in fire risk areas.

Physical separation between DCS and SIS may not be necessary provided independence is maintained.

Which value should I consider as process value when measuring by using three transmitters?

If three transmitters are used, the middle of the three readings can be used (mid-value selection). Mid value selection is advantageous over comparison to the average because the average is skewed by the device that is not functioning properly.

Can FAT be considered part of validation plant?

The factory acceptance test is sometimes referred to as an integration test and can be part of the validation. Although conducting a Factory Acceptance Test (FAT) is not a requirement, a FAT is recommended for those logic solvers implementing safety instrumented functions having fairly complex application logic or redundancy arrangement.

If the SIS has already been through a factory acceptance test (FAT), this may be taken into consideration during the validation. The validation team should review the results of the FAT to ensure that all of the application software was successfully tested and all problems found during the FAT have been corrected.

It may be unnecessary to repeat application software testing at the final validation. This is applicable when

  • This approach was anticipated and included in the validation planning
  • The application software has been verified to meet the safety requirements specification during the FAT, and
  • The application software version is verified to be the identical version tested at the FAT

The equivalent of a proof test is strongly recommended in order to claim SIS validation, because a separate test of the logic solver and the field elements does not equal a complete end-to-end proof test.

What is requirement for application software verification?

To reduce errors due to preconceived mindsets, the verification should include:

  • For SIL 1, a peer review by another member of the application development team
  • For SIL 2, a peer review by a person who is not a member of the application development team
  • For SIL 3, a peer review by a person who is a member of an independent department

What are AU IEC 61511 requirements for Proof Testing intervals?

The proof test interval should be selected to achieve the average probability of failure on demand as required in the safety requirements specification. The frequency of proof tests should be consistent with application manufacturer’s recommendations and good engineering practices, and more frequently, if determined to be necessary by prior operating experience. In the choice of proof test intervals, consideration should be given to the demand rate for demand mode systems, the failure rate of each component being tested, and the overall system performance requirements.

As stated in IEC 61511-1, inspecting the SIS is different from proof testing. Whereas a proof test is ensuring the SIS will be operate properly, a visual inspection is required to validate the mechanical integrity of the installation. Normally, the inspection is done at the same time as the proof test but it may be done at a more frequent interval if desired.

Each SIS shall be periodically visually inspected to ensure there are no unauthorised modifications and no observable deterioration (for example, missing bolts or instrument covers, rusted brackets, open wires, broken conduits, broken heat tracing, and missing insulation).

It is important to document the result of the proof test and inspection for a record of what was found. There are no specific requirements for how long these results should be retained but generally a sufficient number are retained to allow for re-examination of previous results to see if there is a history of component failure.

Is it possible to install maintenance override for periodic testing?

For periodic testing of all elements of the SIS, a methodology for maintenance override is typically necessary to allow on-line testing without shutting down the process under control. Some users will require switches wired through digital input points to initiate maintenance override. Other will use controlled data input to the SIS from a display station. In any case, secure handling has to be ensured to avoid unintended overrides. Maintenance overrides should be announced. The installation of bypasses may reduce the level of security in a SIS. This reduction in security may be overcome by using passwords and/or key locked switches.

If a component of a SIS be selected based on the prior use, which safety levels can be achieved?

Logic solver is selected based on prior use (IEC61511) can be used for SIL1 only. Initiator and final elements which are selected based on prior use can be used for SIL1, SIL2 and SIL3.

Are IEC 61508 and IEC 61511 been regarded as law in Australia?

These two standards are regarded by Australian Work Safety Regulators as best practice. However AS 3814 makes reference to IEC 61508 and IEC 61511 when programmable electronic systems (PES) are used for the burner management system (BMS). AS 3814 is mandated for new gas-fired appliances or when they are modified or relocated. AS 3814 is directly referenced by state gas safety regulations and is thus law. As AS 61508 is referenced by AS 3814, it is also law for gas installations.

What is difference between systematic failures and random failures?

Systematic failures occur when the system is capable of operating but it does not perform its intended function (eg software unexpectedly crashes. A software error is generated; the device does not function as intended). Systematic failures are caused by design fault, maintenance and installation error. They are difficult to be predicted and estimated and not considered in integrity level verifications.

Random failures occur randomly due to “things wearing out”, can be estimated and predicted by using mean time between failure (MTBF) or Failure Rate data. MTBF is a measure of the average time until a components fail. Random failures are defined in different modes as below.

Dangerous mode: are failures that prevent the protective system from initiating a plant shutdown when a dangerous process demand arises. Such failures are undetectable except at the time of proof testing. Diagnostics also are used to uncover dangerous failures. Therefore dangerous mode failures are divided to detected and un-detected failures. In SIL calculations probability to fail on demand (PFD) is calculated just based on undetected dangerous failure rate. Diagnostic coverage is the ratio of failures that are dangerous and diagnosed by internal diagnostic check to overall dangerous failure.

PFDAvg = ʎdu TI / 2

PDFAvg: The probability to fail on demand average

TI: Proof Testing Interval

ʎdu: undetected dangerous failure rate

Safe modes: are failures that cause the safety system to initiate a plant shutdown even though process demands are not present. These spurious failures are safe but reduce the reliability and availability of the system.

Can I trust SIL certifications provided by valve manufacturers?

I do not rely only on SIL information provided by valve vendors. Do not restrict your decision on SIL certifications.

Is it necessary to perform proof testing for a SIS valve used in continues mode?

For valves used continuously (not on demand), the proof testing is meaningless. They should be replaced after the period recommended by vendor.

What are requirements for functions rated SIL0?

The recommendation is keep them as alarm and implement them in DCS to trip the process if required. They can also be implemented in SIS.

How can I calculate occupancy factor in LOPA SIL assessment?

Occupancy is a factor showing likelihood of people presence in time of hazard occurrence. It is recommended to do not consider less than 0.1 for occupancy factor.

Occupancy factor = (number of operators × their presence on site (hours/day) × 365 (days/year)) / 8760 (hours/year)

What is difference between low-demand-mode SIF and continues-mode SIF?

Demand mode is defined as a process variable such as high level, high pressure, high or low temperature, etc., meets a given target (e.g. set point) so as to place a demand on the safety instrumented function to ensure the SIF places the process to a safe state e.g. shut down. The mode of operation is categorized by the demand frequency i.e. how often would a safety function get a demand to operate per year. The IEC 61508/IEC 61511 define two modes of operation:

  1. Low demand mode: where the frequency of demand for operation made on a safety related system is no greater than one per year and no greater than twice the proof-test frequency.
  2. High demand or continues mode: where the frequency of demands for operation made on a safety-related system is greater than one per year or greater than twice the proof check frequency.

Process demand is an estimation of the number of times per year that the SIS will be required to shut down the process or place it in the safe state. Process demands can be determined from past history of the process unit or by modelling the process. High demand modes must be avoided by better process design. SIFs functioning as shutdown are normally low demand.

It is possible to implement continues-mode SIFs and low-demand-mode SIFs in one SIS. Separate calculation shall be made for them. Note that demand rate is defined in safety instrumented functions (SIF) not on equipment.

It is common in market to use expression of SIL rated for components. Is it right expression?

A component cannot be SIL rated (wrong expression in market). A component can be suitable to use in a specific level of integrity (e.g. SIL2). Safety integrity level (SIL) is level to function integrity not a piece of equipment which is part of that.

What is difference between Reliability and availability?

Reliability: probability that an item will perform its required function in the specified manner and under specified or assumed conditions over a given time period. Expressed in safe failure rate and time R(t)=eʎst . Reliability is a measure of system success for a certain period of time. No spurious failure and subsequent repairs are allowed. When failure and repairs need to be considered, then the term availability is used.

Availability: probability that an item will perform its required function in the specified manner and under specified or assumed conditions at a given time.

Availability = MTTF / (MTTF+MDT) = 1-ʎs MDT

MTTF: Mean Time To Fail = surface below R(t)MTTF

MDT: Mean Down Time

ʎs: safe fail rate

Why it is usual to use energized as healthy in fire & gas systems?

To avoid nuisance trips which would be costly. Also to avoid unwanted functioning of fire & gas system if power is off.

What are the different methods of determining the required safety integrity level?

There are a number of ways of establishing the required safety integrity level for a specific application. The method selected for the specific application will depend on many factors, including:

  • The complexity of the application
  • The guidelines from regulatory authorities
  • The nature of the risk and the required risk reduction
  • The experience and skills of the persons available to undertake the work
  • The information available on the parameters relevant to the risk.

The SIL methods are:

  1. ALARP (As Low As Reasonably Practicable)
  2. Modified HAZOP
  3. Consequence only method
  4. Risk Matrices
  5. Risk Graph – Qualitative
  6. Risk Graph – Calibrated
  7. Quantitative Analysis
  8. Layer Of Protection Analysis (LOPA)
  9. Semi-Quantitative
  10. User Defined

What are different methods of SIL verification?

  • Reliability Block Diagrams
  • Markov Model Method
  • Simplified Equations
  • Fault Tree Analysis (FTA)

Is it acceptable to consider the operator’s reaction as a result of alarm a factor for risk reduction?

Where an operator, as a result of an alarm, takes action and the risk reduction claimed in greater than a factor of 10, then the overall system will need to be designed according to IEC 61511-1. It should be noted that a risk reduction of up to a factor of 10 might be claimed without the need to comply with IEC 61511.

Is it acceptable to consider DCS as an independent protection layer in LOPA?

It depends if the initiating cause is a DCS loop, then DCS cannot be count as an IPL. Alarms being annunciated on the DCS are also not independent of the DCS. However, a DCS loop whose normal control can compensate for the cause can be counted as an IPL.

A basic process control system (BPCS) is composed of sensor(s), PLC and actuator(S). The PLC itself is more reliable than sensors and actuators. Therefore as an example if loss of sensor in an initiating cause and if DCS can continue the control by using the redundant sensor, if implemented, then DCS can be counted as IPL as mentioned above.

Typically have a PFD of 1×10-2 (or 1×10-1) for operator response to alarm or for a DCS loop.

Which software can be used for SIL verification?

Exsilentia and Saphire are two softwares which can be used for SIL verification. Exsilentia uses Markov models to calculate PFD of system. Saphire is more recommended for fault tree analysis.

Where should power supply trip to SIS be considered in calculations?

Power supply trip to SIS is not considered in SIL calculations because it is detected safe fault. But need to be considered in reliability calculations.

Is there any guideline for SIS design?

  • use redundancy (sensors and final elements) to improve safety and/or reliability
  • use analogue devices rather than discrete devices whenever possible
  • separate the SIS and the BPCS
  • Eliminate or minimize common mode failures
  • Verify and document interlock functionality
  • Design effective alarm systems
  • Keep the SIS design simple
  • Understand the failure modes
  • Use known technology
  • Test protective systems periodically
  • Ensure management control of changes and system bypasses

How do you compare safety and reliability for different voting configurations?

1oo1

1oo2(3…n) 2oo2

2oo3

Safety

Low

High Low

High

Reliability

Low

Low High

High

Program the SIS in such a way that if one of 2oo3 sensors is BadSignal, changes the voting configuration to 1oo2 to keep safety in high level.

Is there any guideline for deviation alarming?

  • Redundancy provides opportunity for deviation alarming.
  • For triplicated analogue inputs, use percent deviation from median select.
  • For digital device utilize logic function to identify difference of one, from the other two.
  • For dual analogue inputs, alarm on deviation from each other in any direction.
  • For high/low alarms with three analogue inputs, use median selected value for alarm.
  • For high/low alarms with two analogue inputs, alarm on any of signals.

Back to technical Q&A