IRIS Repair coding Why and How Brief History

IRIS Repair coding: Why and How

Brief History of IRIS F In the mid ‘ 80 s, 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 coding development F F F The current European format of IRIS coding was developed in Sony in 1986. The name IRIS stands for INTERNATIONAL REPAIR INFORMATION SYSTEM 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 F F F 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 F F F 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 F For the Manufacturer: u u F 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: u u 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 FEEDBACK (to Design & Production): - Design improvements Input from different Sources - Quality Assurance ANALYSIS & PROCESSING - Warranty administration FEEDFORWARD (to the Field): - Bulletins & Repair Tips - Troubleshooting help (Guides, PC software. . . ) - On-line ‘Knowledge base’

IRIS coding is not a static system F F 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 Flag

IRIS Coding card - Symptom area ’ R E M O T M I A L SC S U C When looking at the IRIS coding card, the Front side (the famous matrix) represents the ‘Symptom’ area ….

IRIS Coding card - Diagnosis area A I SD IS S O N G ’ N A I NIC T H C E …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 Problem Area

Symptom Code structure 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 properation 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” F 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: E 542

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 F F F 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 F F Consist of 3 -byte 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

Example of Section codes in a CD player

Part Identification F F 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 F Lengths of these codes can vary , they should be aligned from left side

Defect Identification F F F “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 “selfstanding”, 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.

Repair Identification F F F 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. .

Parts Quantity F 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).

Parts Flag F 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.

Some typical repair examples F F 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 IC 101 in the Colour processing circuit, and replaces it; this doesn’t solve the problem however. * After further troubleshooting, he finds a badly soldered resistor R 123 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 CPA = colour processing, analog the flags indicate the parts that were found to be the cause of each symptom defect unknown A = replaced D = resoldered THR = threading mechanism T = bad contact 2626 = (intermittently) irregular unloading of tape A = worn out TPT = tape path section Note that first original symptom code was extended, and the second one corrected, by the technician! E = cleaned

No parts used F F F 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.

F Poor coding : we can only know “some adjustment” took place F Better coding : Torque Potentiometer now we know exactly which adjustment was done Alignment

Reference of microphone F 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 F 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… F The result can be rather bad. F F F

Microphone G: scratched / D : cut, broken Power problem 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

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

S/B modification F F F 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

Shaky / unstable BULLETIN REFERENCE F 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 F In many cases it is important to know more exactly on which part of a component some action was performed : * * * F 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

F F F Q 312#C : Collector of Q 312 on which a solder bridge was taken away (defect code X = bridged soldering) IC 001#31 : Pin 31 of IC 001 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.

F F D 600#- : the Anode (- side) of D 600 was resoldered (cold or no soldering) CN 123#5 : pin 5 of CN 123 was repaired (defect code T = bad contact , repair code G = repaired electrical parts)

F F T 805 -FV : Focus adjustment by FV regulator , located on T 805 transformer (defect code P = misaligned , repair code C = electrical alignment) TU 101 -RV : AGC adjustment by RV regulator located in the TU 101 block

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