IRIS Repair coding:

Why

and

How

Brief History of IRIS



In the mid ‘80s, Sony launched the ‘Upstream Action’ quality concept.

Basic principles were: * Factories are themselves fully responsible for the quality of the products they produce; they consequently must bear the cost of the first year’s Warranty Repairs.

* However, to tackle any quality- and reliability problems efficiently, after-sales service must ensure that factories are informed quickly, and in full detail, about their products’ behaviour on the market.

It became thus a necessity to gather and feed detailed service data back from the field as quickly as possible

Gathering Repair Data in Europe ....was faced with several difficult problems:

* Different countries * Different languages * Different types of organisation * Majority of service work performed by external companies (Authorised Servicers and -Dealers

)

So, here Sony discovered a clear need to develop a unified, simple, language-independent, yet powerful “Repair Description Language”

IRIS Basic Introduction & Course

IRIS coding development

     The current European format of IRIS coding was developed in Sony in 1986. The name IRIS stands for

I NTERNATIONAL R EPAIR I NFORMATION S YSTEM

In 1989, the codes were standardised between Sony Europe and Sony Japan (but called ‘ISIS’ in Japan), while a simpler 3-byte variant was used in Sony America.

In 1993, the Japanese Manufacturer’s Standardisation Committee(*) agreed to standardise on Sony ISIS coding for their data gathering from overseas).

In the UK, major Manufacturers (members of BREMA) adopted IRIS in 1992 as their standard. In 1994, Simavelec in France and FIAR in Holland also agreed to promote IRIS as a standard coding language.

(*) Hitachi, JVC, Matsushita, Mitsubishi, Sanyo, Sharp, Sony and Toshiba

Official IRIS standardisation in Europe

   End 1994, the EACEM (European Association for Consumer Electronics Manufacturers) started activities via the EASSC (European After-Sales Service Committee) to promote IRIS coding and a common Warranty data format throughout Europe. An official Recommendation was issued in 1995.

As a result, today, in most European countries, IRIS has become the official or the ‘de facto’ repair data coding standard for Brown goods.

Other Industries (White goods, small appliances, etc. are currently developing their own codes as well, using the same coding structure.

(and remaining compatible with the ‘original’ IRIS coding)

Advantage of IRIS for the Servicer

   Repair Coding * Is a large step towards a fully structured and computerised repair administration.

Standardised Data Structures * Allow simplified Warranty reporting with different Manufacturers, and faster administrative handling of Warranty Claimbacks.

* Form the basis for Electronic Data Interchange (EDI) between Servicers and Manufacturers Structured Technical Data * Allow better technical information handling and faster and more professional repairs * Gathered experience allows for quick and correct cost estimations * More complete and informative invoices for endusers can be made automatically, if necessary in several languages

IRIS coding: a common interest

 For the Manufacturer:  Coded Repair data are the key information that steers and speeds up the Product Quality Improvement Cycle.  Thanks to repair coding, correct tools can be developed to greatly increase the efficiency of the repair work.

 For the Servicer:  Structured repair data allow for a more professional repair administration with far less effort  Repair experience and know-how can be better kept and re-used, and even shared on a large-scale, international level

Better-quality Products combined with more efficient and better-quality Service will greatly increase Customer Satisfaction

Use of Repair Data by the Manufacturer

Input from different Sources ANALYSIS & PROCESSING

FEEDBACK

(to Design & Production): - Design improvements - Quality Assurance - Warranty administration

FEEDFORWARD

(to the Field): - Bulletins & Repair Tips - Troubleshooting help (Guides, PC software...) - On line ‘Knowledge base’

IRIS Basic Introduction & Course

IRIS coding is not a static system

    As the Consumer A/V technology changes very fast, IRIS codes are being evaluated and updated on a regular basis. This is done by an EACEM sub-committee, in which major Manufacturers meet on a regular basis to dicuss the need for changes in the coding.

Any member of EACEM, or even any user of IRIS, can propose additional codes, which will then be discussed by the members of the IRIS sub-committee and eventually officialised.

To ensure world-wide compatibility, any changes are also discussed with similar committees in other zones of the world, before becoming officially accepted.

Basics of IRIS Coding (1)

IRIS coding has two, quite distinct, areas: SYMPTOM AREA The SYMPTOM area is intended to describe the set’s malfunction, AS PERCEIVED BY THE USER or any other casual observer. It requires no specific technician know-how to be filled out, and it uses the •

Condition code

•

Symptom Code

DIAGNOSIS AREA The DIAGNOSIS area is intended FOR THE TECHNICIAN, to describe where the defect was located, and the actions that were taken by him to repair the set.

It uses the •

Section- & (optionally) PCB Code

•

Part Reference(s)

•

Defect Code(s)

•

Repair Code(s)

•

Repair Flag IRIS Basic Introduction & Course

IRIS Coding card - Symptom area

When looking at the IRIS coding card, the Front side (the famous matrix) represents the ‘Symptom’ area ….

IRIS Coding card - Diagnosis area

…whereas the Back side, (with the Section-, Repair- and Defect codes, represents the ‘Diagnosis’ area

The Symptom Code Logic

IRIS Coding card - Symptom area

The Symptom code should describe the problem as it can be perceived by any of the five senses, based on simple questions which the enduser can answer, like:

•

What exactly did (or did you not)

see, hear, feel, smell, taste,….

?

•

Does this phenomenon occur all the time, or under certain conditions?

Nobody should expect a technical analysis from a customer, so it is important to define only symptoms that anybody can perceive and describe.

Basic Symptom Matrix structure

Problem Type 4 5 6 7 8 1 NO ACTION 2 LEVEL 3 QUALITY 4 NOISE 5 UNSTABLE 6 RECORDING & PHYSICAL PROBLEMS 7 SPECIAL FUNCTIONS 8 OTHER CONDITIONS 1 GENERAL

11 POWER 12 CHARGING 13 DISPLAY 14 ABNORMAL NOISE 15 REMOTE CONTROL 16 PHYSICAL DAMAGE 17 GENERAL FUNCTION 18 SPECIAL REQUIREMENTS

2 COMMUNICATION

21

3 PICTURE

31 NO RECEPTION NO PICTURE 22 32 POOR RECEPTION PICTURE LEVEL PROBLEM 23 33 TRANSMISSION PROBLEM PICTURE QUALITY PROBLEM 24 34 NOISY RECEPTION/ TRANSMISSION PICTURE NOISE 25 UNSTABLE RECEPTION/ TRANSMISSION 26 35 UNSTABLE PICTURE 36 TUNING PROBLEM POOR PICTURE RECORDING 27 SPECIAL COMMUNICATION PROBLEM 28 SPECIAL RECEPTION PROBLEM 37 SPECIAL PICTURE FUNCTION 38 PICTURE DISPLAY/PICKUP PROBLEM

COLOUR AUDIO MECHANISM DATA PRINTING

41 NO COLOUR 42 COLOUR LEVEL PROBLEM 43 POOR COLOUR QUALITY 44 NOISY COLOUR 45 UNSTABLE COLOUR 46 POOR COLOUR RECORDING 47 SPECIAL COLOUR FUNCTION 48 51 61 NO MECHANICAL OPERATION 62 71 81 NO AUDIO NO DATA PROCESSING OPERATION NO PRINTER OPERATION 52 72 82 AUDIO LEVEL PROBLEM 53 AUDIO QUALITY 54 NOISY AUDIO 55 UNSTABLE AUDIO 56 POOR AUDIO RECORDING IRREGULAR MECHANICAL OPERATION FAULTY DATA PROCESSING OPERATION ERRONEOUS PRINTER OPERATION 63 73 83 SPEED PROBLEM 64 DATA DISPLAY PROBLEM POOR PRINT QUALITY 74 84 MECHANICAL NOISE 65 75 MECHANICALLY UNSTABLE 66 76 NOISY PRINTING 85 UNSTABLE PRINTER OPERATION 86 DAMAGE TO SOFTWARE 67 DATA READ/ WRITE PROBLEM 77 RIBBON/ PAPER PROBLEM 87 57 POOR SPECIAL AUDIO PROBLEM 58 STEREO/ MULTIMODE OPERATION MECHANICAL OPERATION PROBLEM 68 SPECIAL DATA PROCESSING FUNCTION 78 LENS PROBLEMS 88 FAULTY FONT/ CHARACTER FUNCTIONS

1 2

Symptom Code structure

3 4

Main Symptom Specification

Questions: Byte 1: Under which circumstances? (condition) Byte 2: Which main function group? (area of problem) Byte 3: Which type of malfunction? (type of problem) Byte 4: Which malfunction exactly?(problem specification)

Symptom coding by the Technician ?

Looks like a resource conflict on the SCSI bus master !

When I pushed ‘save’, it suddenly exploded !

By lack of symptom from Customer- or Reception-side, it is often necessary that the technician has to verify the symptom (by testing the set’s proper operation at the work bench), and then enters the Symptom code himself.

But in such a case he/she also should take the same point of view of a customer : WHAT DO I SEE , HEAR , FEEL , SMELL ,... He should NOT try to make an ‘on-the-spot’ diagnosis !

Symptom code “correction”

 In some cases it can also be necessary that a technician will: * * “enhance” the original customer claim, e.g. by adding a condition code.

or he may even have to “correct” it, if it was clearly a wrong one.

But of course also in such case , the basic idea of symptom coding should remain intact.

Examples of good technician corrections:

1. Customer claim: There’s no picture on my TV; this will be coded at reception into

1310

. Technician however finds that in fact the set does not switch on power at all. He consequently corrects to : No Power (code

1110

), or better: No Power on AC (code

1111

) 2. Customer claim: Hiss noise from my cassette; this will be coded at reception to

1542

. Technician finds out this is correct but in fact only appears in one channel. He consequently corrects to:

E542

Value of two different perceptions

• • Some country’s or servicer’s computer systems allow to enter a symptom code on two levels, one ‘Customer’ code and one ‘Technician’ code. • This can actually be quite beneficial, as it also allows to analyse the differences in perception between a customer and a specialist, which can help in cases like “No Defect Found” and others.

Unfortunately, at present, there is no standard way defined yet in IRIS to clearly distinguish, and transmit, two levels of ‘Symptom’ code; therefore in most cases there will still be a regular need for “technician correction” of the Customer’s Symptom code, as descibed higher.

The Diagnosis Code Logic

Diagnosis Area

 By entering a suitable combination of different code types, a technician can give nearly full details concerning the performed repair.

 For each aspect of repair , a specific code is available  By combining the (user) symptom area and the (technician) diagnosis area, a complete picture of the repair can be obtained, and a symptom/ cause analysis can be performed.

Section Identification

 Consist of 3-byte Section codes  Section codes indicate in which part of the set the intervention(s) was (were) performed  To make them easier to remember, the 3-byte codes form so-called ‘mnemonics’ based on the english section names  Section codes are easiest to understand when comparing them to a set’s block diagram

SENSOR UNIT SNS

Example of Section codes in a CD player

REMOTE CONTROL SECTION REM MEMORY CIRCUIT MEM CONTROL PANEL CTR INFORMATION DISPLAY IDS 88 : 88 PROGRAMMING SECTION PRG SYSTEM CONTROL SECTION SYS CLOCK/TIMER SECTION CLK SERVO SECTION SVO EXTERNAL CONNECTOR (e.g. Phono) EXC SIGNAL OUTPUT OUT SIGNAL PROCESSING DIGITAL DPR AUDIO PROCESSING A/D APA/APD EXTERNAL CONNECTOR (mains plug) EXC MAINS LEAD WIR POWER SUPPLY PSU FLEXIBLE PCB FLX INTERNAL CONNECTOR INC PROTECTION CIRCUIT PRT

Part Identification

 Consists of Partnumber, Reference Number, and (optionally) Mounted Circuit Board code  These codes are

manufacturer dependant

.

* Partnumber is the part order code(s) of replaced part(s) * Ref. is the position reference of the part (necessary if one partnumber is used on different locations) * MCB is the name or code of the board on which the component is located  Lengths of these codes can vary , they should be aligned from left side

Line Symp -tom Part Order code Qty Position Section PCB Defect code Rep.

code Flag

Defect Identification

 “Defect Codes” specify the type of defect(s) that was (were) found by the technician.

 Mechanical as well as Electrical codes are defined.

   Usually, they refer immediately to the part identified on the same line.

However, some types of Defect codes can also be “self standing”, i.e. not related to a specific part.

One of those “independent” Defect codes is “No problem found”; reasons for “NPF” can be further specified.

Line Symp -tom Part Order code Qty Position Section PCB Defect code Rep.

code Flag

Repair Identification

 Repair Codes identify the actions performed by the technician   Most common types of repair, like replacement, cleaning, alignment etc. must be referenced to specific components.

Also here, a number of ‘self-standing’ Repair codes exist, e.g. software upgrading, return without repair, estimation of repair, upgrading, etc..

Line Symp -tom Part Order code Qty Position Section PCB Defect code Rep.

code Flag

Parts Quantity

 Quantity field will indicate how many of a particular part have been replaced.

* Logically, a quantity of more than ‘1’ usually only refers to ‘common’ parts, which have no specific reference code of their own (e.g. screws, washers,…) * In case another action than replacement was taken, ‘quantity’ field must be ‘0’ (zero).

Line Symp -tom Part Order code Qty Position Section PCB Defect code Rep.

code Flag

Parts Flag

 The “Flag” is an indication of the “most important” part * Usually, several different parts are replaced during one repair, although mostly just one part is found to be the real cause of the symptom.

* In case different symptoms are available, one “most important” part should be flagged per symptom.

Line Symp -tom Part Order code Qty Position Section PCB Defect code Rep.

code Flag

Some typical repair examples

  A Video recorder is brought in and customer claims “Set has no colour; sometimes my tapes are damaged”; the receptionist codes these symptoms as respectively “1410” and “1660” The technician’s actions: * When playing a test tape, he sees that the first symptom is indeed present.

* He suspects IC101in the Colour processing circuit, and replaces it; this doesn’t solve the problem however.

* After further troubleshooting, he finds a badly soldered resistor R123 in the same circuit, which by simple resoldering solves the problem.

* Next he tackles the second symptom and checks the mechanism; he sees that cassette unloading sometimes blocks, apparently due to a worn guide (ref. 513) in the threading mechanism. * He replaces the guide in question, and also cleans the tape path. Testing reveals that also this problem is solved.

How this example is coded

1412 = (constantly) no colour in playback Line 1 2 3 4 Symp -tom 1412 2626 CPA = colour processing, analog Part Order code 123456 345678 987654 Qty 1 1 Position IC101 R123 513 Section CPA CPA THR TPT the flags indicate the parts that were found to be the cause of each symptom defect unknown PCB XY-3 XY-3 Defect code T A Rep.

code A D A E Flag X X 2626 = (intermittently) irregular unloading of tape THR = threading mechanism TPT = tape path section T = bad contact A = replaced D = resoldered E = cleaned A = worn out

Note that first original symptom code was extended, and the second one corrected, by the technician!

No parts used

 When no parts are used , some fields are even more important for analysis  Defect , Repair code as well as Section code should now give a good view on the problem and solution.

 Suppose a cassette deck is damaging tapes , the customer claims this.

 The technician finds the torque needs adjusting , and no parts need to be replaced.

 Correct and complete encoding will now make all the difference for later analysis.

 Poor coding :

Line 1 Symp -tom 2663 Part Order code Qty Position Section TDM PCB Defect code P Rep.

code B Flag Alignment

we can only know “some adjustment” took place  Better coding :

Line 1 Symp -tom 2663 Part Order code Qty Position RV701 Section TDM PCB SYSC ON Defect code P Rep.

code B Flag Torque Potentiometer

now we know exactly which adjustment was done

Line 1 Symp -tom 1230 Part Order code Qty Position 9 Section PCB MIC Defect code C Rep.

code B Flag Reference of microphone Misaligned Alignment

 In the above example , the reference to the microphone , along with the correct MIC section code give us the information which part was not correctly aligned.

Symptom problem

 Following is an example how NOT to use symptom coding.

 Suppose the customer did not give a clear symptom ,   Or the person who at the frontline did not take care properly Or somebody was just being lazy…  The result can be rather bad.

3 4 1 2 5 6 7 Line Symp -tom 1110 1110 1110 1110 1110 1110 1110 Part Order code X33720696 X33721241 392953101 392953041 A3642683A 392954202 150178211 Qty 1 1 1 1 1 1 1 Power problem Position 9 14 53 15 10 3 1 Section MIC CBT CBT CBT CBT CBT ANT PCB G G D Defect code A G G G Rep.

code A A A A A A A Flag Microphone G: scratched / D : cut, broken Battery cover, screw , connector cover , case assy , antenna ring Antenna

This symptom does NOT match any of the parts !!

Maybe it was entered as such at reception, but the technician should have corrected it

Line 3 4 1 2 5 6 7 Symp -tom 1518 1161 1161 1161 1161 1169 1169 Part Order code X33720696 X33721241 392953101 392953041 A3642683A 392954202 150178211 Qty 1 1 1 1 1 1 1 Position 9 14 53 15 10 3 1 Section PCB MIC CBT CBT CBT CBT CBT ANT G G D Defect code A G G G A A A Rep.

code A A A A Flag

The same repair with corrected codes gives a lot more information !!

S/B modification

 A repair can be solved by applying a Service- or Technical Bulletin  In this case , a specific repair code (I) exists  It is however requested that the reference of the bulletin which was applied is also given; it can be inserted in the REF field

Line 1 Symp -tom 1531 Part Order code X12345678 Qty 1 Position DA00299 Section TPT BULLETIN REFERENCE PCB Defect code J I Rep.

code Flag Shaky / unstable S/B MODFICATION

 In the example above, an audio problem was solved by applying a modification kit which was announced in a technical bulletin

Advanced coding

 In many cases it is important to know more exactly on which part of a component some action was performed : * on which IC pin was a resolder performed * which part of a connector was cleaned or resoldered * which PWB pattern was restored * which alignment was performed on which point * which data parameter was changed  The reference (position) field can also here be used to give more exact information for these purposes

Line 1 2 Symp -tom 1351 111A Part Order code Qty Position Q312#C IC001#31 Section PCB VPA SYS A A Defect code X W Rep.

code D D Flag 1 1

 Q312#C : Collector of Q312 on which a solder bridge was taken away (defect code X = bridged soldering)  IC001#31 : Pin 31 of IC001 was resoldered (defect code W = cold or no soldering)  The use of “

#

“ as a separator after the part reference thus lets the technician inform more details where on a component the action was performed.

Line 1 2 Symp tom 211D 1517 Part Order code Qty Position D600# A CN1123#5 Section PSU INC PCB D A Defect code W T Rep.

code D G Flag 1 1  D600#- : the Anode (- side) of D600 was resoldered (cold or no soldering)  CN123#5 : pin 5 of CN123 was repaired (defect code T = bad contact , repair code G = repaired electrical parts)

Line 1 2 Symp -tom 1332 1C34 5 Part Order code Qty Position T805#FV TU101#RV Section PCB DFL FC D A Defect code P P Rep.

code C C Flag 1 1

 T805-FV : Focus adjustment by FV regulator , located on T805 transformer (defect code P = misaligned , repair code C = electrical alignment)  TU101-RV : AGC adjustment by RV regulator located in the TU101 block

Line 1 2 Symp -tom 1339 1321 Part Order code Qty Position -V-Size TT49 Section PCB MEM MEM A A Defect code P 1 Rep.

code 1 1 Flag 1 1

 -V-Size : V-size was reduced in service mode (defect code P = misaligned , repair code 1 = software correction  TT49 : TT49 was performed , which means an NVM reset and consequent recovering of its contents (defect code 1 = software problem