Machinery Safety Labels: 3 Top Tools for Effective Warnings

This entry is part 4 of 4 in the series Hierarchy of Controls

Machinery Safety Labels

The third level of the Hierarchy of Controls is Information for Use. Safety Labels are a key part of the Information for Use provided by machine build­ers to users and are often the only inform­a­tion that many users get to see. This makes the design and place­ment of the safety labels crit­ic­al to their effect­ive­ness. There is as much risk in the under-​use of safety labels as there is in the over-​use of safety labels. Often, machine build­ers and users simply select gen­er­ic labels that are eas­ily avail­able from cata­logues, miss­ing the oppor­tun­ity to design labels that are spe­cif­ic to the machine and the haz­ards present.

Product Safety and Liability Limitation

If your com­pany man­u­fac­tures machinery that has poten­tial haz­ards asso­ci­ated with its trans­port­a­tion, install­a­tion, use, main­ten­ance, decom­mis­sion­ing and/​or dis­pos­al, you likely have a very strong need to cre­ate effect­ive product safety labels. This task must be done right: product safety labels play an integ­ral role in your company’s product safety and liab­il­ity pre­ven­tion efforts. And that means that people’s lives and your company’s fin­an­cial well-​being are on the line. On that note, it’s import­ant to keep in mind these two factors when it comes to effect­ive safety labels:

1. If prop­erly designed, they can dra­mat­ic­ally reduce acci­dents. This not only improves a product’s over­all safety record but adds to a company’s bot­tom line by redu­cing product liab­il­ity lit­ig­a­tion and insur­ance costs.
2. If poorly designed, needed safety com­mu­nic­a­tion does not take place and this can lead to acci­dents that cause injur­ies. With these acci­dents, com­pan­ies face high costs set­tling or fight­ing law­suits because their products lacked “adequate warn­ings.”

With the rise in product liab­il­ity lit­ig­a­tion based on “fail­ure to warn” over the past sev­er­al dec­ades, product safety labels have become a lead­ing focal point in law­suits faced by cap­it­al equip­ment man­u­fac­tur­ers. Let’s look at three best?practice tools for product safety label design. These tools can provide insight to help you cre­ate or improve your safety label strategy in order to bet­ter pro­tect your product users from harm and your com­pany from litigation-​related losses.

TOOL #1: SAFETY LABEL STANDARDS

As a man­u­fac­turer, you know that your leg­al oblig­a­tion is to meet or exceed the most recent ver­sions of stand­ards related to your product at the time it’s sold into the mar­ket­place. Warning label stand­ards are the first place to turn to when it comes to defin­ing your product safety labels. Up until 1991, there was no over­arch­ing, multi-​industry stand­ard in the U.S., or in the rest of the world, which gave defin­it­ive guid­ance on the prop­er format­ting and con­tent for on-​product warn­ings. In the U.S., that changed nation­ally with the pub­lic­a­tion of the ANSI Z535.4 Standard for Product Safety Signs and Labels in 1991, and inter­na­tion­ally with the pub­lic­a­tion of ISO 3864 – 2 Design Principles for Product Safety Labels in 2004.

As of 2017, Canada does not have a warn­ing label stand­ard. Since Canada imports machinery from the U.S. and the EU, it is quite com­mon to see either ANSI Z535 style labels or ISO 3864 style labels on products. Under Canadian law, neither is more cor­rect. However, Québec has spe­cif­ic require­ments for French lan­guage trans­la­tions, and many CSA stand­ards pre­scribe spe­cif­ic haz­ard warn­ing labels that do not con­form to either ANSI or ISO styles.

Following the design prin­ciples in ANSI Z535.4 or ISO 3864 – 2 will give you a start­ing place for both the con­tent and format choices you have to make for your products’ safety labels, bear­ing in mind the lan­guage require­ments of your jur­is­dic­tion. Note that both of these stand­ards are revised reg­u­larly, every five years or so, and it’s import­ant to be aware of the nuances that would make one format more appro­pri­ate for your product than anoth­er.

TOOL #2: RISK ASSESSMENT

From an engin­eer­ing per­spect­ive, your job is to identi­fy poten­tial haz­ards and then determ­ine if they need to be designed out, guarded, or warned about. From a leg­al per­spect­ive, your job is to define what haz­ards are “reas­on­ably fore­see­able” and “reas­on­able” ways to mit­ig­ate risks asso­ci­ated with haz­ards that can­not be designed out. This is where risk assess­ment comes into play.

In today’s world, a product is expec­ted to be designed with safety in mind. The risk assess­ment pro­cess helps you to accom­plish this task. At its most basic level, risk assess­ment involves con­sid­er­ing the prob­ab­il­ity and sever­ity of out­comes that can res­ult from poten­tially haz­ard­ous situ­ations. After identi­fy­ing the poten­tial haz­ards related to your product at every point in its life­cycle, you then con­sider vari­ous strategies to either elim­in­ate or reduce the risk of people inter­act­ing with these haz­ards.

The best prac­tice risk assess­ment stand­ards that exist today (i.e. ANSI Z10, ANSI B11, CSA Z432, CSA Z1002, ISO 12100, ISO 31000, ISO 31010) give you a pro­cess to use to quanti­fy and reduce risks. Using these stand­ards as the basis for a form­al­ized risk assess­ment pro­cess will not only help you to devel­op bet­ter safety labels and a safer product, but it will also provide you with doc­u­ment­a­tion that will help you to show the world that you are a safety-​conscious com­pany who uses the latest standards-​based tech­no­logy to reduce risks. This will be highly import­ant should you be involved in product liab­il­ity lit­ig­a­tion down the road.

From an engin­eer­ing per­spect­ive, your job is to identi­fy poten­tial haz­ards and then determ­ine if they need to be designed out, guarded, or warned about. From a leg­al per­spect­ive, your job is to define what haz­ards are “reas­on­ably fore­see­able” and “reas­on­able” ways to mit­ig­ate risks asso­ci­ated with haz­ards that can­not be designed out. This is where risk assess­ment comes into play.

TOOL #3: PICTOGRAPHIC  SAFETY LABELS FOR GLOBAL MARKETS

A large num­ber of machinery man­u­fac­tur­ers sell their products around the globe and when this is the case, com­pli­ance with glob­al stand­ards is a require­ment. The ANSI Z535.4 and ISO 3864 – 2 product safety label stand­ards, and the EU machinery dir­ect­ive place an emphas­is on using well-​designed sym­bols on machinery safety labels so inform­a­tion can be con­veyed across lan­guage bar­ri­ers.

The EU Machinery Directive 2006/​42/​EC requires that all inform­a­tion for use be provided in the offi­cial lan­guages of the coun­try of use. Information for use includes haz­ard warn­ing signs and labels that bear mes­sages in text. Adding sym­bols also increases your labels’ notice­ab­il­ity. The use of sym­bols to con­vey safety is becom­ing com­mon­place world­wide and not tak­ing advant­age of this new visu­al lan­guage risks mak­ing your product’s safety labels obsol­ete and non-​compliant with loc­al, region­al and inter­na­tion­al codes. In ISO 3864 – 2’s latest, 2016 update, a major change in ISO label formats was made: a new “word­less” format that con­veys risk sever­ity was added to the stand­ard. This new label format uses what ISO calls a “haz­ard sever­ity pan­el” but no sig­nal word. It com­mu­nic­ates the level of risk through colour-​coding of the haz­ard sever­ity pan­el. This format option elim­in­ates words – mak­ing trans­la­tions unne­ces­sary.

It should be noted that some­times sym­bols alone can­not con­vey com­plex safety mes­sages. In these cases, text is often still used. When ship­ping to non-​English speak­ing coun­tries, the trend today is to trans­late the text into the lan­guage of the coun­try in which the machine is sold. Digital print tech­no­logy makes this solu­tion much more cost effect­ive and effi­cient than in the past.

Concluding Thoughts

The safety labels that appear on your products are one of its most vis­ible com­pon­ents. If they don’t meet cur­rent stand­ards, if they aren’t designed as the res­ult of a risk assess­ment, and if they don’t incor­por­ate well-​designed graph­ic­al sym­bols, your com­pany risks lit­ig­a­tion and non-​conformance with mar­ket require­ments. Most import­antly, you may be put­ting those who inter­act with your machinery at risk of harm. Making sure your product safety labels are up-​to-​date is an import­ant task for every engin­eer respons­ible for a machine’s design.

For more inform­a­tion on effect­ive product safety labelling and resources that you can put to use today, vis­it www​.clari​on​safety​.com. Clarion also offers com­pli­ment­ary safety label assess­ments, where we use our exper­i­ence with the latest stand­ards and best prac­tices to assess your labels and ensure that they’re up-​to-​date in meet­ing today’s require­ments.

Acknowledgements: Derek Eversdyke, Clarion Safety Systems, LLC
Some Rights Reserved

ISO 13849 – 1 Analysis — Part 5: Diagnostic Coverage (DC)

This entry is part 5 of 9 in the series How to do a 13849 – 1 ana­lys­is

What is Diagnostic Coverage?

Understanding Diagnostic Coverage (DC) as it is used in ISO 13849 – 1 [1] is crit­ic­al to ana­lys­ing the design of any safety func­tion assessed using this stand­ard. In case you missed a pre­vi­ous part of the series, you can read it here.

In the last instal­ment of this series dis­cuss­ing MTTFD, I brought up the fact that everything fails even­tu­ally, and so everything has a nat­ur­al fail­ure rate. The bathtub curve shown at the top of this post shows a typ­ic­al fail­ure rate curve for most products. Failure rates tell you the aver­age time (or some­times the mean time) it takes for com­pon­ents or sys­tems to fail. Failure rates are expressed in many ways, MTTFD and PFHd being the ways rel­ev­ant to this dis­cus­sion of ISO 13849 ana­lys­is. MTTFis giv­en in years, and PFHd is giv­en in frac­tion­al hours (1/​h). As a remind­er, PFHd stands for “Probability of dan­ger­ous Failure per Hour”.

Three of the stand­ard archi­tec­tures include auto­mat­ic dia­gnost­ic func­tions, Categories 2, 3 and 4. As soon as we add dia­gnostics to the sys­tem, we need to know what faults the dia­gnostics can detect and how many of the dan­ger­ous fail­ures rel­at­ive to the total num­ber of fail­ures that rep­res­ents. Diagnostic Coverage (DC) rep­res­ents the ratio of dan­ger­ous fail­ures that can be detec­ted to the total dan­ger­ous fail­ures that could occur, expressed as a per­cent­age. There will be some fail­ures that do not res­ult in a dan­ger­ous fail­ure, and those fail­ures are excluded from DC because we don’t need to worry about them – if they occur, the sys­tem will not fail into a dan­ger­ous state.

Here’s the form­al defin­i­tion from [1]:

3.1.26 dia­gnost­ic cov­er­age (DC)

meas­ure of the effect­ive­ness of dia­gnostics, which may be determ­ined as the ratio between the fail­ure rate of detec­ted dan­ger­ous fail­ures and the fail­ure rate of total dan­ger­ous fail­ures

Note 1 to entry: Diagnostic cov­er­age can exist for the whole or parts of a safety-​related sys­tem. For example, dia­gnost­ic cov­er­age could exist for sensors and/​or logic sys­tem and/​or final ele­ments. [SOURCE: IEC 61508 – 4:1998, 3.8.6, mod­i­fied.]

That brings up two oth­er related defin­i­tions that need to be kept in mind [1]:

3.1.4 fail­ure

ter­min­a­tion of the abil­ity of an item to per­form a required func­tion

Note 1 to entry: After a fail­ure, the item has a fault.

Note 2 to entry: “Failure” is an event, as dis­tin­guished from “fault”, which is a state.

Note 3 to entry: The concept as defined does not apply to items con­sist­ing of soft­ware only.

Note 4 to entry: Failures which only affect the avail­ab­il­ity of the pro­cess under con­trol are out­side of the scope of this part of ISO 13849. [SOURCE: IEC 60050 – 191:1990, 04 – 01.]

and the most import­ant one [1]:

3.1.5 dan­ger­ous fail­ure

fail­ure which has the poten­tial to put the SRP/​CS in a haz­ard­ous or fail-​to-​function state

Note 1 to entry: Whether or not the poten­tial is real­ized can depend on the chan­nel archi­tec­ture of the sys­tem; in redund­ant sys­tems a dan­ger­ous hard­ware fail­ure is less likely to lead to the over­all dan­ger­ous or fail-​to- func­tion state.

Note 2 to entry: [SOURCE: IEC 61508 – 4, 3.6.7, mod­i­fied.]

Just as a remind­er, SRP/​CS stands for “safety-​related parts of con­trol sys­tems”.

Failure Math

Failure Rate Data Sources

To do any cal­cu­la­tions, we need data, and this is true for fail­ure rates as well. ISO 13849 – 1 provides some tables in the annexes that list some com­mon types of com­pon­ents and their asso­ci­ated fail­ure rates, and there are more fail­ure rate tables in ISO 13849 – 2. A word of cau­tion here: Do not mix sources of fail­ure rate data, as the con­di­tions under which that data is true won’t match the data in ISO 13849. There are a few good sources of fail­ure rate data out there, for example, MIL-​HDBK-​217, Reliability Prediction of Electronic Equipment [15], as well as the data­base main­tained by Exida. In any case, use a single source for your fail­ure rate data.

Failure Rate Variables

IEC 61508 [7] defines a num­ber of vari­ables related to fail­ure rates. The lower­case Greek let­ter lambda, $\lambda$, is used to denote fail­ures.

The com­mon vari­able des­ig­na­tions used are:

$\lambda$ = fail­ures
$\lambda_{(t)}$= fail­ure rate
$\lambda_s$ = “safe” fail­ures
$\lambda_d$ = “dan­ger­ous” fail­ures
$\lambda_{dd}$ = detect­able “dan­ger­ous” fail­ures
$\lambda_{du}$ = undetect­able “dan­ger­ous” fail­ures

Calculating DC

Of these vari­ables, we only need to con­cern ourselves with $\lambda_d$, $\lambda_{dd}$ and $\lambda_{du}$. To under­stand how these vari­ables are used, we can express their rela­tion­ship as

$\lambda_d=\lambda_{dd}+\lambda_{du}$

Following on that idea, the Diagnostic Coverage can be expressed as a per­cent­age like this:

$DC\%=\frac{\lambda_{dd}}{\lambda_d}\times 100$

Determining DC%

If you want to actu­ally cal­cu­late DC%, you have some work ahead of you. Rather than going into the details here, I am going to refer you hard­core types to IEC 61508 – 2, Functional safety of electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems – Part 2: Requirements for electrical/​electronic/​programmable elec­tron­ic safety-​related sys­tems. This stand­ard goes into some depth on how to determ­ine fail­ure rates and how to cal­cu­late the “Safe Failure Fraction,” a num­ber which is related to DC but is not the same.

For every­one else, the good news is that you can use the table in Annex E to estim­ate the DC%. It’s worth not­ing here that Annex E is “Informative.” In standards-​speak, this means that the inform­a­tion in the annex is not part of the “norm­at­ive” text, which means that it is simply inform­a­tion to help you use the norm­at­ive part of the stand­ard. The design must con­form to the require­ments in the norm­at­ive text if you want to claim con­form­ity to the stand­ard. The fact that [1, Annex E] is inform­at­ive gives you the option to cal­cu­late the DC% value rather than select­ing it from Table E.1. Using the cal­cu­lated value would not viol­ate the require­ments in the norm­at­ive text.

If you are using IFA SISTEMA [16] to do the cal­cu­la­tions for you, you will find that the soft­ware lim­its you to select­ing a single DC meas­ure from Table E.1, and this prin­ciple applies if you are doing the cal­cu­la­tions by hand too. Only one item from Table E.1 can be selec­ted for a giv­en safety func­tion.

Ranking DC

Once you have determ­ined the DC for a safety func­tion, you need to com­pare the DC value against [1, Table 5] to see if the DC is suf­fi­cient for the PLr you are try­ing to achieve. Table 5 bins the DC res­ults into four ranges. Just like bin­ning the PFHd val­ues into five ranges helps to pre­vent pre­ci­sion bias in estim­at­ing the prob­ab­il­ity of fail­ure of the com­plete sys­tem or safety func­tion, the ranges in Table 5 helps to pre­vent pre­ci­sion bias in the cal­cu­lated or selec­ted DC val­ues.

If the DC value was high enough for the PLr, then you are done with this part of the work. If not, you will need to go back to your design and add addi­tion­al dia­gnost­ic fea­tures so that you can either select a high­er cov­er­age from [1, Table E.1] or cal­cu­late a high­er value using [14].

Multiple safety functions

When you have mul­tiple safety func­tions that make up a com­plete safety sys­tem, for example, an emer­gency stop func­tion and a guard inter­lock­ing func­tion, the DC val­ues need to be aver­aged to determ­ine the over­all DC for the com­plete sys­tem. [1, Annex E] provides you with a meth­od to do this in Equation E.1.

Plug in the val­ues for MTTFD and DC for each safety func­tion, and cal­cu­late the res­ult­ing DCavg value for the com­plete sys­tem.

That’s it for this art­icle. The next part will cov­er Common Cause Failures (CCF). Look for it on 20-​Mar-​17!

In case you missed the first part of the series, you can read it here.

Book List

Here are some books that I think you may find help­ful on this jour­ney:

[0.2]  Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.

References

Note: This ref­er­ence list starts in Part 1 of the series, so “miss­ing” ref­er­ences may show in oth­er parts of the series. Included in the last post of the series is the com­plete ref­er­ence list.

[16]     “IFA – Practical aids: Software-​Assistent SISTEMA: Safety Integrity – Software Tool for the Evaluation of Machine Applications”, Dguv​.de, 2017. [Online]. Available: http://​www​.dguv​.de/​i​f​a​/​p​r​a​x​i​s​h​i​l​f​e​n​/​p​r​a​c​t​i​c​a​l​-​s​o​l​u​t​i​o​n​s​-​m​a​c​h​i​n​e​-​s​a​f​e​t​y​/​s​o​f​t​w​a​r​e​-​s​i​s​t​e​m​a​/​i​n​d​e​x​.​jsp. [Accessed: 30- Jan- 2017].

ISO 13849 – 1 Analysis — Part 2: Safety Requirement Specification

This entry is part 2 of 9 in the series How to do a 13849 – 1 ana­lys­is

Developing the Safety Requirement Specification

The Safety Requirement Specification sounds pretty heavy, but actu­ally, it is just a big name for a way to organ­ise the inform­a­tion you need to have to ana­lyse and design the safety sys­tems for your machinery. Note that I am assum­ing that you are doing this in the “right” order, mean­ing that you are plan­ning the design before­hand, rather than try­ing to back-​fill the doc­u­ment­a­tion after com­plet­ing the design. In either case, the pro­cess is the same, but get­ting the inform­a­tion you need can be much harder after the fact, than before the doing the design work. Doing some aspects in a review mode is impossible, espe­cially if a third party to whom you have no access did the design work [8].

If you missed the first instal­ment in this series, you can read it here.

What goes into a Safety Requirements Specification?

For ref­er­ence, chapter 5 of ISO 13849 – 1 [1] cov­ers safety require­ment spe­cific­a­tions to some degree, but it needs some cla­ri­fic­a­tion I think. First of all, what is a safety func­tion?

Safety func­tions include any func­tion of the machine that has a dir­ect pro­tect­ive effect for the work­er using the machinery. However, using this defin­i­tion, it is pos­sible to ignore some import­ant func­tions. Complementary pro­tect­ive meas­ures, like emer­gency stop, can be missed because they are usu­ally “after the fact”, i.e., the injury occurs, and then the E-​stop is pressed, so you can­not say that it has a “dir­ect pro­tect­ive effect”. If we look at the defin­i­tions in [1], we find:

3.1.20

safety func­tion

func­tion of the machine whose fail­ure can res­ult in an imme­di­ate increase of the risk(s)
[SOURCE: ISO 12100:2010, 3.30.]

Referring to the risk assess­ment, any risk con­trol that pro­tects work­ers from some aspect of the machine oper­a­tion using a con­trol func­tion like an inter­locked gate, or by main­tain­ing a tem­per­at­ure below a crit­ic­al level or speed at a safe level, is a safety func­tion. For example: if the tem­per­at­ure in a pro­cess rises too high, the pro­cess will explode; or if a shaft speed is too high (or too low) the tool may shat­ter and eject broken pieces at high speed. Therefore, the tem­per­at­ure con­trol func­tion and the speed con­trol func­tion are safety func­tions. These func­tions may also be pro­cess con­trol func­tions, but the poten­tial for an imme­di­ate increase in risk due to a fail­ure is what makes these func­tions safety func­tions no mat­ter what else they may do.

[1, Table 8] gives you some examples of vari­ous kinds of safety func­tions found on machines. The table is not inclus­ive – mean­ing there are many more safety func­tions out there than are lis­ted in the table. Your job is to fig­ure out which ones live in your machine. It is a bit like Pokemon – ya gotta catch ‘em all!

Basic Safety Requirement Specification

Each safety func­tion must have a Performance Level or a Safety Integrity Level assigned as part of the risk assess­ment. For each safety func­tion, you need to devel­op the fol­low­ing inform­a­tion:

Basic Safety Requirement Specification
Item Description
Safety Function Identification Name or oth­er ref­er­ences, e.g. “Access Gate Interlock” or “Hazard Zone 2.”
Functional Characteristics
• Intended use or fore­see­able mis­use of the machine rel­ev­ant to the safety func­tion
• Operating modes rel­ev­ant to the safety func­tion
• Cycle time of the machine
• Response time of the safety func­tion
Emergency Operation Is this an emer­gency oper­a­tion func­tion? If yes, what types of emer­gen­cies might be mit­ig­ated by this func­tion?
Interactions What oper­at­ing modes require this func­tion to be oper­a­tion­al? Are there modes where this func­tion requires delib­er­ate bypass? These could include nor­mal work­ing modes (auto­mat­ic, manu­al, set-​up, changeover), and fault-​finding or main­ten­ance modes.
Behaviour How you want the sys­tem to behave when the safety func­tion is triggered, i.e., Power is imme­di­ately removed from the MIG weld­er using an IEC 60204 – 1 Category 0 stop func­tion, and robot motions are stopped using IEC 60204 – 1 Category 1 stop func­tion through the robot safety stop input.

or

All hori­zont­al pneu­mat­ic motions stop in their cur­rent pos­i­tions. Vertical motions return to the raised or retrac­ted pos­i­tions.

Also to be con­sidered is a power loss con­di­tion. Should the sys­tem behave in the same way as if the safety func­tion was triggered, not react at all, or do some­thing else? Consider ver­tic­al axes that might require hold­ing brakes or oth­er mech­an­isms to pre­vent power loss caus­ing unex­pec­ted motion.

Machine State after trig­ger­ing What is the expec­ted state of the machine after trig­ger­ing the safety func­tion? What is the recov­ery pro­cess?
Frequency of Operation How often do you expect this safety func­tion to be used? A reas­on­able estim­ate is needed. More on this below.
Priority of Operation If sim­ul­tan­eous trig­ger­ing of mul­tiple safety func­tions is pos­sible, which function(s) takes pre­ced­ence? E.g., Emergency Stop always takes pre­ced­ence over everything else. What hap­pens if you have a safe speed func­tion and a guard inter­lock that are asso­ci­ated because the inter­lock is part of a guard­ing func­tion cov­er­ing a shaft, and you need to troubleshoot the safe speed func­tion, so you need access to the shaft where the encoders are moun­ted?
Required Performance Level I sug­gest record­ing the S, F, and P val­ues selec­ted as well as the PLr value selec­ted for later ref­er­ence.

Here’s an example table in MS Word format that you can use as a start­ing point for your SRS doc­u­ments. Note that SRS can be much more detailed than this. If you want more inform­a­tion on this, read IEC 61508 – 1, 7.10.2.

So, that is the min­im­um. You can add lots more inform­a­tion to the min­im­um require­ments, but this will get you star­ted. If you want more inform­a­tion on devel­op­ing the SRS, you will need to get a copy of IEC 61508 [7].

What’s Next?

Next, you need to be able to make some design decisions about sys­tem archi­tec­ture and com­pon­ents. Circuit archi­tec­tures have been dis­cussed at some length on the MS101 blog in the past, so I am not going to go through them again in this series. Instead, I will show you how to choose an archi­tec­ture based on your design goals in the next instal­ment. In case you missed the first part of the series, you can read it here.

Book List

Here are some books that I think you may find help­ful on this jour­ney:

[0.2]  Electromagnetic Compatibility for Functional Safety, 1st ed. Stevenage, UK: The Institution of Engineering and Technology, 2008.

References

Note: This ref­er­ence list starts in Part 1 of the series, so “miss­ing” ref­er­ences may show in oth­er parts of the series. Included in the last post of the series is the com­plete ref­er­ence list.