Functional Safety: IEC 61508 vs ISO 26262 Explained
Component suppliers are increasingly asked about their ASIL and their functional safety capability. Picture a typical (fictional) case: a Japanese automaker or Tier 1 sends a request for quotation (RFQ). One line asks for the "ASIL" of your part, and another asks whether you "support kino anzen (機能安全, functional safety)."
Your product already carries a SIL 2 certificate under IEC 61508, so the answer looks easy. It isn't.
IEC 61508 is the general functional safety standard for all industries. ISO 26262 adapts it for road vehicles. The two share the same core ideas but set safety levels in different ways, so a SIL rating does not convert directly into an ASIL.
This guide explains what functional safety means, how the two standards are built, where SIL and ASIL differ, how the Japanese standard JIS C 0508 fits in, and what work products a Japanese customer is likely to expect. It ends with a checklist and a sample inquiry email.
Contents
- What Is Functional Safety?
- How the Functional Safety Standards Fit Together
- IEC 61508 at a Glance
- ISO 26262 at a Glance
- IEC 61508 vs. ISO 26262: Key Differences
- What Functional Safety Development Involves
- What a Japanese Customer Will Likely Ask For
- SOTIF, Cybersecurity, and Upcoming Revisions
- Limits of This Guide
- FAQ
- Sources
What Is Functional Safety?
Functional safety means reducing risk to an acceptable level by making sure safety functions work correctly when needed. A sensor that detects an abnormal condition and closes a fuel shutoff valve is one example. A controller that detects a fault and stops a motor, putting the machine in a safe state, is another.
IEC 61508 defines functional safety as the part of overall safety that depends on electrical, electronic, and programmable electronic (E/E/PE) safety-related systems working correctly. ISO 26262 describes it as the absence of unreasonable risk from hazards caused by malfunctioning electrical and electronic (E/E) systems.
In both standards, "safe" does not mean "accidents never happen." Safety is defined as freedom from unacceptable risk. The starting assumption is that risk can never reach zero, so the goal is to bring the remaining risk down to a level people can accept.
Functional Safety vs. Inherent Safety
Functional safety is often contrasted with inherent safety, called honshitsu anzen (本質安全) in Japanese. Inherent safety removes or reduces the hazard itself. A railway example: a grade separation (an overpass or underpass) removes any chance of a train hitting a car.
A grade crossing (level crossing), by contrast, relies on safety functions: warning lights and gates. Building grade separations everywhere is not practical, so the two approaches play complementary roles. Functional safety reduces the risk that inherent safety cannot remove.
The comparison below shows how the two approaches differ in practice.
Remove the source of the hazard, or control it with a function. Real products combine both.
Functional safety does not replace inherent safety. It reduces the risk that remains after inherent safety measures.
Why Functional Safety Standards Emerged
For a long time, Japanese manufacturers protected safety mainly by making components more reliable and driving failures toward zero. That approach does not plan for components having faults or bugs in the first place.
As equipment grew larger and more complex, and safety controls started to use programmable logic controllers (PLCs) and other microprocessor-based electronics, unexpected failures caused by the interaction of hardware and software became possible. Older standards that specified component construction in detail could not cover what happens inside a microprocessor.
The answer was a performance-based standard: assume failures will happen, and keep the probability that they lead to a hazard within an acceptable range. Major process plant accidents in Europe from the 1970s onward, and the tighter regulation that followed, are often cited as the background to IEC 61508.
Two Types of Failure
Functional safety splits failures into two groups. Random hardware failures, such as component wear-out, occur at unpredictable times. Systematic failures come from specification errors, design mistakes, software bugs, or process gaps.
Random failures can be estimated from failure-rate data. Systematic failures cannot be quantified statistically.
So the standards handle them in two ways: random failures through numeric targets and diagnostics, systematic failures through a disciplined development process. That split explains why the requirements fall into both "calculations" and "procedures."
Different causes call for different countermeasures.
Software does not wear out, so all software faults are treated as systematic failures.
How the Functional Safety Standards Fit Together
Functional safety standards branch out from one parent, IEC 61508. Within the IEC system, it holds the status of a basic safety publication for functional safety.
Because IEC 61508 covers every industry, it is hard for non-specialists to see which requirements apply to their own product and how. Sector standards and product standards were written to make the requirements concrete for each field.
IEC 61508 is the parent. Sector and product standards build on it.
Products with no sector or product standard (such as process temperature transmitters) apply IEC 61508 directly. ISO 13849 is also widely used for machinery safety controls.
In a chemical plant, for example, the company that designs and operates the safety instrumented system works to IEC 61511. The makers of the sensors and shutoff valves built into that system design to IEC 61508. The same installation can involve different standards depending on your role.
For factory machinery, ISO 13849 and IEC 62061 set the safety performance of control systems; this is why collaborative robot projects ask about safety function performance. Medical devices are an exception: products that comply with the IEC 60601 series do not use IEC 61508 as their basic safety publication.
Where JIS C 0508 Fits
JIS C 0508 is the Japanese Industrial Standard (JIS) version of IEC 61508, first adopted in Japan around 1999–2000. The current parts correspond to IEC 61508:2010 (Edition 2), and Japan published them in stages: Parts 1 and 4 in 2012, Parts 2 and 3 in 2014, Part 7 in 2017, and Parts 5 and 6 in 2019.
If a Japanese drawing or specification cites "JIS C 0508," treat it as a pointer to IEC 61508:2010. JSA states that the JIS editions keep the technical content of the IEC text unchanged. If a contract cites a specific JIS year, confirm with the customer which IEC edition they expect you to follow.
We found no JIS adoption of ISO 26262. Japanese automotive customers normally cite ISO 26262 itself.
IEC 61508 at a Glance
IEC 61508 is the international standard for E/E/PE safety-related systems. The current edition is Edition 2, published in 2010, and the IEC is preparing the next edition (see the last section).
Seven Parts
The standard has seven parts. Parts 1–4 contain the requirements: general requirements, hardware requirements, software requirements, and definitions. Parts 5–7 are guidelines that collect design and analysis techniques you can use to meet those requirements.
In practice, Part 1 covers how the overall system is handled, Part 2 covers circuits and hardware, and Part 3 covers software. Even when these are split among different engineers, everyone should share the thinking in Part 1.
Safety Integrity Level (SIL)
At the center of IEC 61508 is the safety integrity level (SIL). It rates the reliability required of a safety function on four levels: SIL 4 is the most demanding and SIL 1 the least.
The SIL is assigned from a risk analysis by estimating how much risk reduction the safety function must provide. The numeric target depends on how often the function is called on:
- Low-demand mode (demanded no more than once a year): the average probability that the function fails to work on demand (PFDavg).
- High-demand or continuous mode (demanded more often, or working all the time): the average frequency of dangerous failures per hour (PFH).
Each step up in SIL lowers the allowed value by one order of magnitude, as the table shows.
Each SIL step tightens the target by a factor of 10.
PFDavg (average probability of failure on demand)
PFH (dangerous failures per hour)
Source: "Functional Safety Utilization Text," Japan Industrial Safety & Health Association, commissioned by Japan's Ministry of Health, Labour and Welfare (Japanese). These targets cover random hardware failures. Systematic failures are handled with development methods matched to the SIL.
Meeting these targets depends on more than component failure rates. The redundancy architecture, the share of dangerous failures that self-diagnostics can detect (diagnostic coverage), and the proof-test interval all count. For example, duplicating the logic solver lets the safety function continue even if one channel fails.
The Overall Safety Lifecycle
The second pillar of IEC 61508 is the overall safety lifecycle, which divides everything from concept to disposal into 16 phases.
It starts with the concept, the scope definition, and hazard and risk analysis. Then come the definition and allocation of safety requirements and the realization of the safety-related systems. Installation and commissioning, validation, operation and maintenance, modification, and decommissioning complete the cycle.
The key point is that responsibility for safety continues through maintenance and modification, not just until delivery. When several companies work on one plant, the first practical step is to confirm which lifecycle phases your company owns.
ISO 26262 at a Glance
ISO 26262 adapts IEC 61508 to the E/E systems of road vehicles. The first edition came out in 2011 and covered series-production passenger cars with a gross vehicle mass of up to 3,500 kg (about 7,700 lb).
The second edition, published in December 2018, extended the scope to all series-production road vehicles, including trucks and buses (but excluding mopeds). It also grew from 10 parts to 12, adding guidelines for semiconductors (Part 11) and an adaptation for motorcycles (Part 12). ISO 26262:2018 is still the current edition.
Twelve Parts
The 12 parts fall into four groups: management, development, supporting processes, and guidelines. Development is split by level (system, hardware, software), so engineers usually focus on the part that matches their work.
Sorting the parts into management, development, support, and guidance makes the structure easier to grasp.
Parts 3–7 link the stages of product development in a V-model.
How an ASIL Is Determined
Instead of SIL, ISO 26262 uses the Automotive Safety Integrity Level (ASIL). There are four levels, A to D: ASIL D is the most demanding and ASIL A the least.
When a hazard needs no functional safety requirements, it is rated QM (quality management) and handled by normal quality processes. The ASIL, or QM, is set for each hazardous event that a vehicle function could cause if it malfunctions.
Three factors are rated: severity (S), exposure (E), and controllability (C). Take the event "the vehicle fails to steer as needed on a curve at highway speed." You would assess how badly people could be hurt, how often vehicles are in that driving situation, and whether the driver could regain control.
Each hazardous event is rated for S, E, and C. The combination sets the ASIL.
The ASIL is set for hazardous events of the item (a vehicle-level function). Safety requirements derived from it are then passed down to each component.
Explanatory material often lists airbags and electric power steering as ASIL D examples, and air conditioning and infotainment as QM examples. But the actual ASIL depends on how the vehicle is used and how the function is designed. A part name alone does not determine the ASIL.
This hazard analysis and risk assessment (HARA) follows the same basic framework as a workplace risk assessment: identify hazards, then rate them by severity and likelihood. The differences are that it covers everyone on the road, not just workers, and it adds controllability, a factor specific to vehicles.
IEC 61508 vs. ISO 26262: Key Differences
Because ISO 26262 is built on IEC 61508, the two share the split between random and systematic failures, safety management across the whole lifecycle, and confirmation by independent parties. ISO 26262 then changes several points to suit mass production and the automotive supply chain.
A parent standard and a sector standard, with different ways of setting levels and different scopes.
SIL and ASIL are set in different ways, so one cannot simply be converted into the other.
The two levels are easy to mix up. This table puts SIL and ASIL side by side.
| Item | SIL (IEC 61508) | ASIL (ISO 26262) |
|---|---|---|
| Levels | Four: SIL 1–SIL 4 | Four: ASIL A–ASIL D |
| Strictest level | SIL 4 | ASIL D |
| How it is set | From the required risk reduction | From severity, exposure, and controllability |
| Hardware targets | PFDavg and PFH ranges | SPFM, LFM, and PMHF target values |
| When not applicable | No SIL assigned | QM, handled by normal quality management |
| Main fields | Plants, machinery, equipment, all industries | Series-production road vehicles |
Why SIL and ASIL Don't Map One-to-One
A common misunderstanding is a simple conversion such as "ASIL D equals SIL 3." A SIL comes from the required risk reduction and links directly to a probability range. An ASIL comes from a combination of severity, exposure, and controllability, and the standard then sets methods and target values for each ASIL.
ISO 26262 gives no normative or informative mapping between the two. Pairings like "ASIL D is roughly SIL 3" do appear in commercial literature, but treat them as rough orientation at best, not as evidence a customer will accept.
This applies in both directions. Whether an industrial supplier is moving into automotive or an automotive supplier is moving into industrial equipment, "SIL-certified" does not automatically mean "usable in a vehicle." Recheck the requirements against the target standard.
Supplier Responsibilities Are Built into ISO 26262
Vehicles are built through a split of work: the automaker (OEM) at the top, then Tier 1, Tier 2, and many more parts makers. ISO 26262 therefore includes requirements for the relationship between customer and supplier.
When development is shared, the parties usually agree in a development interface agreement (DIA) on who is responsible for which safety activities and work products. In the automotive supply chain, a parts supplier is the party that receives safety requirements and returns evidence that they are met.
If the scope of functional safety work is not confirmed at the quotation stage, unplanned analyses and documents can appear mid-project and drive up engineering hours.
What Functional Safety Development Involves
This section uses ISO 26262 as the example. IEC 61508 uses different names and details, but the underlying structure is the same.
Vehicle-level safety goals are broken down into system, hardware, and software requirements, then verified in reverse order.
Safety management (Part 2) and configuration management, change management, and documentation (Part 8) run in parallel through every stage.
Linking Requirements from Top to Bottom
Requirements are refined step by step: from vehicle-level safety goals to functional safety requirements, technical safety requirements, and then hardware and software requirements. On the right side of the V-model, tests confirm that each requirement has been met.
What the standard demands here is traceability: being able to show which requirement went into which design element and which test confirmed it. The basic embedded software workflow does not change much, but recording the links between requirements and tests adds a lot of work.
Finding Weak Points Early with Safety Analysis
At each design stage, engineers analyze how a failure could violate a safety goal. FMEA (failure mode and effects analysis) works bottom-up (inductive), and FTA (fault tree analysis) works top-down (deductive). Teams usually combine the two to avoid gaps.
The methods overlap heavily with the FMEA used in quality management. Functional safety goes further, though: can a safety mechanism detect this failure, and is there enough time to detect it and reach a safe state?
For redundant designs, engineers also check for common cause failures, where one cause takes out both channels at once.
Hardware: Proving It with Numbers
For hardware, three metrics show how robust the design is against random failures:
- SPFM (single-point fault metric): the share of faults that a safety mechanism covers instead of letting them lead directly to a hazard
- LFM (latent fault metric): the share of latent (hidden) faults that are detected or otherwise covered
- PMHF (probabilistic metric for random hardware failures): the probability that random hardware failures violate a safety goal
ISO 26262-5 (hardware level) gives target values for each ASIL. The values below are the ones commonly quoted from the 2018 edition. A FIT is one failure per billion (109) hours.
| ASIL | SPFM | LFM | PMHF |
|---|---|---|---|
| ASIL D | ≥ 99% | ≥ 90% | < 10 FIT |
| ASIL C | ≥ 97% | ≥ 80% | < 100 FIT |
| ASIL B | ≥ 90% | ≥ 60% | < 100 FIT |
| ASIL A | No quantitative targets | ||
The pattern is clear: the higher the ASIL, the more the coverage of self-diagnostics and the accuracy of component failure-rate data matter.
Software: Protecting It with Process
Software faults are systematic, so they are not rated by probability. Instead, the standard recommends methods for each development stage according to the ASIL. Examples include:
- Following coding guidelines
- Static analysis of the design
- Requirements-based testing
- Measuring structural coverage
The reliability of development tools is also in scope. Errors in a compiler or test tool can let defects slip through, so be ready to explain how you used each tool and how you confirmed it works correctly.
Independent Confirmation and Documented Evidence
Functional safety standards require checks by people other than the authors. ISO 26262 defines confirmation measures: confirmation reviews of work products, functional safety audits of the process, and the functional safety assessment. The higher the ASIL, the more independence (a person, department, or organization not involved in the design) is required.
In the end, the analysis results, test results, and review records are assembled into a safety case: a structured argument for why the product is safe enough. Producing documents is not the goal in itself. The goal is that a third party can read them and trace the basis for safety.
Organization and Safety Culture
Before any single project, Part 2 requires an organization-level system for managing functional safety. Its main elements are:
- A safety culture where people report safety problems openly instead of hiding them
- Ensuring staff competence
- A quality management system
- A safety plan for each project
So introducing functional safety cannot stop at the design department. Quality assurance, production engineering, and purchasing are also involved. A typical start is to appoint a functional safety manager and map the gaps between the existing development process and the standard.
What a Japanese Customer Will Likely Ask For
Japanese automakers and Tier 1s set their own templates, so the exact list varies by customer and project. The work products below are the ones suppliers commonly deliver under ISO 26262. Use this list to frame the discussion, and get the real list in writing through the DIA.
- DIA (kaihatsu intafesu goisho, 開発インタフェース合意書): who owns which activity, work product, and confirmation measure
- Safety plan for your scope of work
- Safety requirements you received and how you allocated them
- Hardware metrics report (SPFM, LFM, PMHF), often based on an FMEDA (failure modes, effects, and diagnostic analysis)
- Safety analysis results: FMEA, FTA, dependent failure analysis
- Verification reports with requirement-to-test traceability
- Safety manual (anzen manyuaru, 安全マニュアル) for parts developed without a specific vehicle in mind, called a safety element out of context (SEooC): the assumptions of use and the conditions the integrator must meet
- Evidence of confirmation measures: review records, audit and assessment reports
- Tool confidence evidence for compilers, test tools, and similar
You will also see these Japanese terms in specifications and meeting notes.
| Japanese | Romaji | English |
|---|---|---|
| 機能安全 | kino anzen | functional safety |
| 安全度水準 | anzendo suijun | safety integrity level (SIL) |
| 自動車用安全度水準 | jidoshayo anzendo suijun | ASIL |
| 安全目標 | anzen mokuhyo | safety goal |
| ランダムハードウェア故障 | randamu hadowea kosho | random hardware failure |
| 決定論的原因故障 | ketteironteki gen'in kosho | systematic failure |
| 診断カバー率 | shindan kaba ritsu | diagnostic coverage |
| 確認方策 | kakunin hosaku | confirmation measures |
| 機能安全アセスメント | kino anzen asesumento | functional safety assessment |
Checklist: Questions to Ask Before You Quote
Confirm these points before you commit to a price or schedule.
- Which standard and edition applies: ISO 26262:2018, IEC 61508:2010 (JIS C 0508), or a sector standard?
- What ASIL (or SIL) applies to the safety requirements allocated to our part? Is any ASIL decomposition planned?
- Are we developing for a specific item, or as a SEooC?
- Which work products must we deliver, in what format and language (Japanese or English), and by which milestones?
- Which confirmation measures must we perform, and what level of independence is required? Will the customer or a third party assess us?
- What failure-rate data sources are accepted for the hardware metrics?
- Is an existing certificate (for example, a SIL certificate) accepted as input, and what extra evidence is needed?
- Who approves changes after start of production, and how are change notices handled?
Sample Inquiry Email
Adapt this short email to open the discussion with a Japanese customer.
Subject: Functional safety scope for [part name] – RFQ [number]
Thank you for the RFQ. Before we finalize our quotation, could you confirm the functional safety scope for this part?
1. Applicable standard and edition (e.g., ISO 26262:2018)
2. ASIL of the safety requirements allocated to our part
3. Whether we develop for a specific item or as a safety element out of context
4. Required work products, format, language, and due milestones
5. Required confirmation measures and level of independenceIf you have a draft development interface agreement (DIA), we would be glad to review it. Our product currently holds [certificate, e.g., SIL 2 under IEC 61508]; please let us know whether you can use it as input.
Best regards,
[Name]
SOTIF, Cybersecurity, and Upcoming Revisions
ISO 26262 covers only risk caused by failures of E/E systems. In automated driving and driver assistance, hazards can occur with nothing broken: a sensor misses a pedestrian in backlight, or the system misjudges an unexpected road situation.
ISO 21448, safety of the intended functionality (SOTIF), published in June 2022, covers risk from insufficient specifications or performance limits. ISO/SAE 21434, published in August 2021, covers vehicle cybersecurity against external attacks.
Automotive development now combines three views: failures (ISO 26262), performance limits (ISO 21448), and attacks (ISO/SAE 21434).
As of late 2026, several parts of the third edition of ISO 26262 (including Parts 3, 6, 7, 8, and 10, according to standards listings) are at the Draft International Standard (DIS) stage; Part 3, for example, entered its DIS ballot on October 14, 2026. Confirm the status of each part on iso.org.
UL Solutions expects the official release sometime in 2027. Until then, ISO 26262:2018 remains the edition to follow.
IEC 61508 Edition 3 is also in development. Committee drafts for vote of some parts circulated in 2025, and the 61508 Association and BSI expect Edition 3 in 2027.
Some listings show Part 3 at a later approval stage with a possible publication in late 2026, so the dates differ by source. Check the IEC Webstore for the current status before you commit to an edition in a contract.
Certification bodies point to topics such as software that uses machine learning, fail-operational designs that keep working after a fault, and alignment with SOTIF. Build your system on the current editions, and keep track of these revisions.
Limits of This Guide
- This is an overview, not a substitute for the standards. Use licensed copies of ISO 26262 and IEC 61508 for design decisions.
- Required work products, templates, and independence levels vary by customer, project, and ASIL. The DIA and the customer's requirements take precedence over any general list.
- Machinery, process, rail, and medical products follow their own sector standards and local regulations. Confirm the applicable standard with your customer, a certification body, or a qualified functional safety professional.
- Revision dates in this article reflect public information as of November 2026 and may change.
FAQ
Is ASIL D the same as SIL 3?
No. ISO 26262 provides no official mapping between ASIL and SIL: a SIL is tied to a failure probability range, while an ASIL comes from severity, exposure, and controllability. Informal pairings such as "ASIL D ≈ SIL 3" are rough orientation only.
Can a SIL-certified component be used in an ISO 26262 project?
Not automatically. The customer will check the part against ISO 26262 requirements and the ASIL allocated to it. An existing SIL certificate and its analyses may serve as input if the customer agrees, so confirm what additional evidence is needed.
Which should come first, inherent safety or functional safety?
Inherent safety. First remove the cause of the hazard by design, then use functional safety to reduce the risk that remains. Functional safety does not replace inherent safety; real products combine both.
Do parts suppliers need to follow ISO 26262?
Yes, when their parts carry safety requirements. ISO 26262 covers the split of work between automakers and suppliers. Confirm at the quotation stage which safety activities and work products you are responsible for, so engineering hours do not balloon mid-project.
Is ISO 26262 enough for automated driving?
No. ISO 26262 covers risk from E/E system failures. Automated driving also needs ISO 21448 (SOTIF) for performance limits such as sensor blind spots, and ISO/SAE 21434 for cybersecurity.
Sources
- Functional safety definitions, standards structure, IEC 61508 parts and overall safety lifecycle: Japan Electric Measuring Instruments Manufacturers' Association (JEMIMA), technical explanation of functional safety standards, November 2013 (Japanese)
- SIL and PFDavg/PFH ranges: Japan Industrial Safety & Health Association, "Functional Safety Utilization Text," commissioned by the Ministry of Health, Labour and Welfare, February 2017 (Japanese)
- IEC 61508-1 edition and date: IEC Webstore, IEC 61508-1:2010
- JIS C 0508 parts and their IEC 61508:2010 counterparts: Japanese Standards Association, JIS C 0508-1:2012 preview (Japanese); JIS C 0508-7:2017 preview (Japanese)
- ISO 26262 scope, relation to IEC 61508, ASIL definition, second-edition changes: ISO 26262-1:2018 preview (iTeh Standards)
- Second edition date and scope expansion: Jama Software, "ISO 26262 Second Edition Introduces Updates"
- S/E/C classes and ASIL examples: Jama Software, "What Is ASIL?"
- Hardware metric targets (SPFM, LFM, PMHF): Chalmers University of Technology, master's thesis "Implementing ISO 26262-5" (2023); G. Schildbach, "On the Application of ISO 26262 in Control Design for Automated Vehicles," EPTCS 269 (2018)
- No official ASIL–SIL mapping: itemis, "SIL" glossary; Wikipedia, "Automotive Safety Integrity Level"
- Supplier work products (DIA, safety manual, FMEDA, SEooC): Renesas, functional safety support for automotive, overview; Texas Instruments, TPS3704-Q1 functional safety documentation (SFFS310A)
- Level crossing and grade separation example: Japan Quality Assurance Organization (JQA), ISO NETWORK Vol. 22 (Japanese)
- ISO 21448 date and definition: ISO, ISO 21448:2022
- ISO/SAE 21434 date: ISO, ISO/SAE 21434:2021
- ISO 26262 third edition, DIS stage: Genorma, ISO/DIS 26262-3
- ISO 26262 third edition, expected timing and topics: UL Solutions, "What to Expect with Version 3 of ISO 26262" (January 2024)
- IEC 61508 Edition 3 drafts and timing: iTeh Standards, prEN IEC 61508-3:2025; 61508 Association, "Standards Development"
Original article in JapaneseThis guide is adapted from a MONOSCOPE article written for readers in Japan: 機能安全とは｜IEC 61508とISO 26262の違いと開発で求められること
About the editor
MONOSCOPE EditorFOUNDER & EDITORSpent about ten years at a plant equipment maker and a plant engineering company, proposing, designing, and commissioning equipment, then moved into web marketing. Now a web consultant for B2B manufacturers, helping them explain their products and technology. Licensed in Japan as an Energy Manager and a Third-Class Chief Electrical Engineer.
Has run an engineering blog since 2017 (500+ articles) and a Japanese YouTube channel with about 20,000 subscribers. Each English guide is written from the Japanese shop-floor point of view and checked against the cited standards.
