IoT in Auto Manufacturing automating the Body-to-Chassis Marriage process, preventively controlling prohibitvely expensive incorrect pairing.

1. Pilot for the Use of
RFID technology
In AUTO MANUFACTURING Domain
(PLEASE NOTE THAT THE CLIENT NAME HAS BEEN BLOCKED TO COMPLY WITH THE NDA)
(This document and the contents within cannot be distributed in any form without the prior consent of SkandSoft
Technologies Limited. This document is for the internal use within the recipient organization. This document can only be
shared with approved personnel within the recipient organization and the law enforcement authorities if need be.)

2. Confidential. Restricted Circulation Only
- 2 -
Contents:
1. Introduction
2. Proposed Solution
a. Process
b. Interface with the host SAP R3
c. Features
d. System Architecture
e. Support
3. Annexures
a. Tagging Section and Hardware Resources
b. Change Management

3. Confidential. Restricted Circulation Only
- 3 -
1. INTRODUCTION
The main objective of the pilot was to establish the robustness and dependency of RFID in
the functional domain. The pilot would also represent the various solution features and
functionalities which could be extended to other functional areas at “xyz”
2. PROPOSED SOLUTION:
a) PROCESS:
TYPICAL WORKFLOW (To be altered on Customer’s Brief)
Assumptions:
• After marriage, the assembled unit is moved out with out being stored
• The solution has access to the relevant tables which contain
o Engine details
o Chassis details
o Model details for successful marriage
Explanation of Legends:
• R1-Reader to record Chassis Number
• R2- Reader to record Engine Number.

4. Confidential. Restricted Circulation Only
- 4 -
• R3- Reader[Handheld] has following functions:
o To pick Right Engine for successful marriage.
o Cross checks the aggregates for valid marriage
o Updates the aggregate tags with marriage details
This handheld also can be replaced by a fixed reader as latching the
fixed reader on LAN will be easier
• R4-Reader which
o Confirms, validates the Successful marriage and alarms in case of
deviation.
PROCESS FLOW:
T1-Table / Equivalent keeping Stock of Chassis by Serial Number
T2-Table/ Equivalent keeping Stock of Engines by Serial Number
T3-Table / Equivalent containing details of Engine Number and Model Number to be for a
particular Model.
1. Chassis arrives at the Chassis Tagging Station and its number is physically read.
Inspection is carried out to verify that this number matches with T1 details hence
ensuring that Chassis Number is unique. After ensuring the above, the unique number
is written on the active Tag with a link to the specific entry in the Chassis Table T1
through Reader R1. The tagged item is moved on the Chassis assembly line.
2. Engine arrives at the Engine Tagging Station and its number is physically read.
Inspection is carried out to verify that this number matches with T2 details hence
ensuring that Engine Number is unique. After ensuring the above, the unique number
is written on the active Tag with a link to the specific entry in the Engine Table T2 through
Reader R2. The tagged item is moved to the storage area.
3. Based on the marriage records, each set of engine and chassis combination is read from
the table T3.
4. Appropriate Engine is removed from the Storage Area. Handheld reader (R3) is used for
this purpose. Engine number/model is identified from table T3. This is Error Proofing on
the first Level.
5. Engine is moved to the Engine fitting station and married to the appropriate Chassis.
Reader R3 captures the details of Successful marriage. Information between the Tags is
also interchanged to capture the details. Read/ Write Active tags are required to ensure
this. This is Error proofing on the second level. Hence Reader R3 does following:-
o To pick Right Engine for successful marriage.
o Cross checks the aggregates for valid marriage
o Updates the aggregate tags with marriage details
6. During exit from Assembly line area R4 checks that only perfectly married aggregates
leave premises. Thus there is on three levels to ensure 100 % Error Proofing.
R4 carries the following activities:

5. Confidential. Restricted Circulation Only
- 5 -
o Confirms, validates the Successful marriage and alarms in case of deviation.
7. After details of Successful marriage have been Captured and Confirmed Tags
are removed to be reused for the next cycle
b. Interface with the host SAP R3 system
There are two methodologies for achieving the interface with the host SAP R3 system:
1.SETUTM
interacts with existing business host system through XML. Both the parties have to
agree on a format and location (of various files) of the XML files. Relevant data from SAP is
output as XML files and SETUTM
fetches records from this XML. The periodicity of updating
such XML files to reflect any changes in SAP has to be decided based on your requirement.
This approach is used if the integration needs to be non-intrusive
2. SETU interacts with R/3 through JavaConnector (JCo – SAP’s own java connector for
external applications). Using JCo, SETUTM
can fetch data from SAP directly without a need to
have an intermediary layer like XML. This does not need explicit updation of files as data are
fetched from SAP itself.
This approach is intrusive as it involves invoking various BAPIs from the JCo, time
consuming but robust.

6. Confidential. Restricted Circulation Only
- 6 -
c) FEATURES
Process
A. Aggregates tagged at
with relevant data
Features
1. Real time validation of Engine and
Chassis number ensure unique
identification and location of the same
2. Status of any of the Aggregates in the
inventory can be checked in real time
across locations and departments.
3. Multilevel checking of the Aggregates to
ensure 100% Error Proofing
4. Tabulating of data only after successful
marriage has been confirmed.
5. In case of repetition of Engine/ Chassis
number Alerts can be fired.
6. In case of Marriage been unsuccessful
errors can be fired at various levels
7. Alerting by e-mail / SMS for specific
events
• Repetition of Engine number
• Repetition of Chassis number
• Unsuccessful marriage
8. Pre-defined customized reports
9. Extend collaboration with other business
process partners within the plant.
10.Extend collaboration with external
vendors
11.Extend real-time impact to other
connected functions like forecasting,
replenishment, inventory management
etc.
B. Tagged aggregates
stored before marriage
C. Aggregates proceed
from storage area to
Assembly Line with
validations pre and post
marriage.
E. Assembly leaves for
the subsequent
processes. Tags to be
removed
D. After Successful
Marriage is validated
Complete Assembly is
verified

7. Confidential. Restricted Circulation Only
- 7 -
SETUTM
Server
DB, Filtering and Event-
Action engine
Reader
RS 232/Eth
Active Tags
Chassis
RS 232/Eth
Reader at
Storage
Passive Tags
Reader at
Storage
Passive Tags
Reader
Active Tags
Engines
SetuTM
Polling AgentsSetuTM
Polling Agents
SETUTM
Clients
Temp DB
User GUI Admin GUI Extension to
Other Apps
d) System Architecture:
• Client is responsible for managing all the reader functions and reader health
monitoring, data collection, parsing and temporary storage
• Server addresses multiple Clients and is responsible for Event filtering, smoothening,
Action and Exception Management. Server also manages the central databases,
which gets data from temporary databases of all Clients.
• All the Clients and the Server to be connected through Ethernet.
• Reader communication through custom protocols and RS232/Eth connectors.
• If the locations are not dispersed, one PC can be configured as both the Server
and the Client.

8. Confidential. Restricted Circulation Only
- 8 -
e) Support :
Documentation
A thorough, easy-to-use, cross-referenced documentation will be provided for the
following aspects of the Solution:
• User Functions Guide
• Admin Configuration Guide
• Admin Functions Guide
• Trouble Shooting Documentation
o Typical Problem Areas
o How to identify the problem area proactively
o Preventive measures
o Step-by-step Root cause analysis guide
o Solutions

9. Confidential. Restricted Circulation Only
- 9 -
3) Annexures
a) Tagging Section and Hardware Resources
RFID Readers
Readers of the following specifications:
Range:
Frequency:
Anti-Collision:
Antennae:
No:
RFID Tags [transponders]
Active
Read-Write
Label Type
Above mentioned components would be decided after mutual consultation to meet a
minimum threshold number of aggregates/components that would qualify for a fully
representative pilot.
PCs:
1 PC – P IV+, 512 MB RAM, 20 GB available disk space
1 Server Class, P IV, 1 GB RAM, 40 GB available disk space
Human Resources:
The following personnel will be deployed at the tagging section:
One data entry/tag writing operator
Human Resources requirements are based on the assumption of one shift. For all three
shifts, the same will be arrived at mutually.
b) Change Management
Changes in the Process:
The following changes are envisaged as per the proposed solution:
1. The new process will achieve:
a. Data entry [customized to specific requirements]
b. Writing the data on an RFID Tag
c. Attaching the RFID tag onto the vehicle at a pre-determined position

10. Confidential. Restricted Circulation Only
- 10 -
2. The resource requirements for this new process has been outlined in Annexure 3(a)
3. The process to collect the RFID tags and re-cycling them would need to be arrived at
after due consultations with the client.
Change Management Process:
• Change Management Committee
• Training / Handholding
• Change Implementation/Transition]
For the above we shall mutually arrive at the joint team and the process in which the change
management would be executed.
3. Tentative Time Schedules
a) Time Required to Start the Project:-
1 week for site study, srs and prototyping, 3 weeks to order for and receive hardware
b) Time required for implementation :-
4 weeks including testing, training and transition
The above timelines could be altered.