Dynamic repair system

Devices, systems, and methods for dynamic repair of bypassed vehicles are disclosed. Information regarding an abnormality (for example, an incorrectly installed joint) occurring in a vehicle being assembled on an assembly line can be captured and recorded in a database. Following a bypass command, the vehicle can be flagged and released to continue down the assembly line to be repaired at a later time. When a user is ready to repair the vehicle, repair instructions specific to the abnormality can be retrieved from a database and presented to the user, and the repair procedure can be monitored to ensure that the abnormality has been repaired correctly. The vehicle can be unflagged only if all abnormalities in the vehicle have been repaired. The vehicle can be prevented from exiting the last station in the assembly line if it remains flagged.

BACKGROUND

This disclosure generally relates to assembly lines for vehicles and more specifically error-proofing systems thereof. Many automotive assembly plants include error proofing (in Japanese, “pokayoke”) systems to maintain quality control as vehicles are assembled on an assembly line. Pokayoke systems typically include controllers stationed at each station of the assembly line, which are used to detect if a process was performed according to predefined standards or thresholds. For example, an assembly process can include a procedure to tighten joints on a vehicle (such as a nut/bolt joint) using an electric or pneumatic nutrunner. During such an assembly process, it is possible that a joint will fail to be tightened at the proper torque or will be tightened at an incorrect angle, which can lead to a cross threaded joint.

Pokayoke controllers are often used to alert users to the existence of these kinds of assembly faults or abnormalities, such as by flashing a light or sounding an alarm, or by causing the assembly line to halt. When this happens, a supervisor is typically called to correct the abnormality. However, there may not be time to correct the abnormality immediately, and so the supervisor will often bypass the pokayoke system by overriding the alarm and restarting the assembly line, intending to repair the vehicle at some point farther down the assembly line.

It is incumbent upon the supervisor issuing the bypass to ensure that the abnormality is eventually corrected. The supervisor must therefore manually keep track of bypassed vehicles throughout the assembly process. However, it is difficult and time consuming for users to accurately record each vehicle and the needed repairs and to later remember all the information necessary to conduct the repair. Therefore, abnormalities in bypassed vehicles are often not tracked effectively and therefore are often not adequately repaired. In addition, because repairs are performed after the vehicle has moved down the assembly line, the tools needed for the repairs are manual tools that are not connected to the pokayoke system.

It has been observed that users tasked with correcting abnormalities such as those described above have been known to: (i) repair the wrong joint, (ii) repair the correct joint on the wrong vehicle, (iii) use an incorrect torque when repairing the joint, (iv) forget to repair the abnormality altogether, and/or (v) fail to log a repair as completed. Thus, due to manual repair tracking, an incorrectly installed joint can remain present after the vehicle is released down the assembly line. Sometimes, even new abnormalities are introduced during the repair process. Additionally, a user may complete a repair but forget to log the repair, negatively impacting traceability and quality control.

SUMMARY

Devices, systems, and methods for dynamic repair of bypassed vehicles are disclosed. Information regarding an abnormality (for example, an incorrectly installed joint) occurring in a vehicle being assembled on an assembly line can be captured and recorded in a database. Following a bypass command, the vehicle can be flagged and released to continue down the assembly line to be repaired at a later time. When a user is ready to repair the vehicle, repair instructions specific to the abnormality can be retrieved from a database and presented to the user, and the repair procedure can be monitored to ensure that the abnormality has been repaired correctly. The vehicle can be unflagged only if all abnormalities in the vehicle have been repaired. The vehicle can be prevented from exiting the last station in the assembly line if it remains flagged.

A computing device for an assembly line is disclosed, comprising: one or more processors for controlling operations of the computing device; and a memory storing data and program instructions used by the one or more processors, wherein the one or more processors are configured to execute instructions stored in the memory to: receive information regarding an abnormality occurring in a vehicle being assembled on the assembly line; flag the vehicle by storing the information regarding the abnormality in a database; monitor a repair of the abnormality; and unflag the vehicle only if the repair of the abnormality is completed successfully.

A method is disclosed, comprising: receiving information regarding an abnormality occurring in a vehicle being assembled on an assembly line; flagging the vehicle by storing the information regarding the abnormality in a database; monitoring a repair of the abnormality; and unflagging the vehicle only if the repair of the abnormality is completed successfully.

A system is disclosed, comprising: a repair tool configured to detect abnormalities in a repair procedure; a computing device comprising: one or more processors for controlling operations of the computing device; and a memory storing data and program instructions used by the one or more processors, wherein the one or more processors are configured to execute instructions stored in the memory to: receive information regarding an abnormality occurring in a vehicle being assembled on an assembly line; flag the vehicle by storing the information regarding the abnormality in a database; monitor a repair of the abnormality; and unflag the vehicle only if the repair of the abnormality is completed successfully.

DETAILED DESCRIPTION

Disclosed herein are devices, systems, and methods for dynamic repair of bypassed vehicles. Information regarding an abnormality occurring in a vehicle being assembled on an assembly line can be recorded in a database, for example, after a user bypasses a pokayoke system to release the vehicle having an abnormality to be repaired at a later time. The disclosed implementations provide an advantage over existing (prior art) methods, wherein a user must manually log a repair needed after bypassing the pokayoke system and releasing the vehicle down the assembly line. Currently, abnormalities often are not repaired properly. In contrast, the disclosed implementations describe integrating the repair process with an existing pokayoke system, so that abnormalities, bypasses, and repairs are automatically confirmed and recorded, thus improving traceability. Accordingly, the disclosed implementations can provide a superior level of protection against quality flow out.

FIG. 1is a schematic block diagram of a computing device100for dynamic repair of a vehicle bypassed in an assembly line. The computing device100can be any type of single computing device (such as a server, desktop, laptop, mobile, or handheld), or can be composed of multiple computing devices. A processing unit in the computing device100can be a conventional central processing unit (CPU)102or any other type of device, or multiple devices, capable of manipulating or processing information. A memory104in the computing device100can be a random access memory device (RAM) or any other suitable type of storage device. The memory104can include data106that is accessed by the CPU102using a bus108.

The memory104can also include an operating system110and installed applications112, the installed applications112including programs or apps that permit the CPU102to implement the dynamic repair features disclosed herein. The computing device100can also include secondary, additional, or external storage114, for example, a memory card, flash drive, or any other form of computer readable medium. In one implementation, the applications112can be stored in whole or in part in the external storage114and loaded into the memory104as needed for processing.

The computing device100can be equipped with a communications interface116to connect to other devices, either directly or over a network118such as a local area network (LAN) or the internet. The communications interface116can be configured to transmit and receive data over a cable (such as a CAT5 network cable) or wirelessly (for example, using a protocol such as 802.11 or Bluetooth™). The computing device100can also include an authentication interface120for identifying authorized users. The authentication interface120can include key card readers, biometric scanners, or other devices used to authenticate users as is known in the art. The computing device100can also include an input/output interface122to connect to devices used to input data into the computing device100or to output data to a user. Example devices include keyboards, displays, audio devices such as microphones and speakers, voice recognition interfaces, and similar devices.

FIG. 2is a pictorial representation of a pokayoke controller200in communication with a nutrunner controller240. The pokayoke controller200can be configured to communicate with the computing device100, for example, over the network118. The pokayoke controller200can be configured to notify users of abnormalities that occur during the assembly process, as described in more detail below. The pokayoke controller200can include a notification light210to alert users to abnormalities. The notification light210can emit colors based on the status of the vehicle—for example, a green light can mean that there are no abnormalities while a red light can mean an abnormality has been detected. Audio alerts can also be used to provide notifications to users.

The nutrunner controller240can be configured to control a nutrunner250used to perform an assembly procedure on a vehicle, for example, tightening a joint (e.g., a nut or a bolt). The nutrunner controller240can set the nutrunner250to operate at a predefined torque when tightening the joint. The nutrunner250can include sensors to detect whether the joint is tightened correctly or not. For example, the nutrunner250can be configured to measure the torque actually applied to the joint (which may at times vary from the desired torque set by the nutrunner controller240) and/or the angle of rotation. The nutrunner controller240can compare the measurements detected by the nutrunner250to predefined acceptable ranges to determine if the assembly procedure was completed successfully or if a fault or abnormality occurred during operation.

FIG. 3is a schematic block diagram of an exemplary assembly line300employing the computing device100ofFIG. 1and the pokayoke controller200ofFIG. 2(along with the connected nutrunner controller240and nutrunner250). The assembly line300can include several stations302for assembling one or more vehicles310. At each station302, a user can be tasked with performing a particular assembly procedure on the vehicle310, for example, tightening joints using the nutrunner250available at such station302. Each station302can be equipped with a pokayoke controller200to notify the user whether the process performed has been completed successfully. The pokayoke controllers200can be connected to the network118in order to communicate with the computing device100.

Abnormalities can and do occasionally occur during assembly, even when the correct torque is programmed into the nutrunner250. For example, a joint may fail to be tightened to the proper torque, or it can be torqued at an incorrect angle causing the bolt to become cross threaded. The nutrunner controller240can be configured to determine if such an abnormality has occurred based on the data detected by the nutrunner250. In a typical scenario, where no abnormality occurs, after the assembly procedure of each station302is complete, the vehicle310is released to the next station302in the assembly line300. However, if an abnormality is detected, the pokayoke controller200can be configured to cause the assembly line300to halt with a “line stop” operation so that a repair can be made to correct the abnormality. The pokayoke controller200can also be configured to alert users to the problem, for example, by flashing the notification light210.

Certain authorized users such as supervisors can be permitted to override the pokayoke system with a bypass command. This can reset the pokayoke controller200and restart the assembly line300, thereby releasing the bypassed vehicle310to the next station302. The authorized user can input the bypass command into the pokayoke controller200. The pokayoke controller200can then provide the bypass command and other information regarding the abnormality to the computing device100.

In one exemplary implementation, the user must be authenticated before being permitted to issue a bypass command. The authentication process can include the user scanning a keycard identifying the user as an authorized user. In one exemplary implementation, the keycard scanner can be integrated into the pokayoke controller200installed at each station302. The pokayoke controller200can send the keycard information to the computing device100, which can authenticate the authorized user using the authentication interface120. Upon authenticating the user, the computing device100can authorize the bypass, which will reset the pokayoke controller200and restart the assembly line300). Other authentication methods can also be used without departing from the spirit and scope of this disclosure; for example, biometric data (e.g., fingerprints, retina scans, etc.) can be used to authenticate the user rather than keycards.

Upon receiving notice of the abnormality and/or bypass command from the pokayoke controller200(and assuming the authorized user is authenticated), the computing device100can record information regarding the abnormality in a database, for example, stored in the memory104or external storage114. This information can include information identifying the vehicle310that is subject to the abnormality and the station302at which the abnormality occurred. The information recorded in the database can also include other details such as the date and time of the abnormality and/or bypass command, the name/badge number of the user working on the vehicle and/or the authorized user that entered the bypass command, etc. The information regarding the abnormality recorded in the database can be used to track the vehicle310having the abnormality and the progress of the repair, as described in more detail below.

FIG. 4is a pictorial representation of a repair tool400used to repair the vehicle310. As discussed above, by issuing a bypass command, the authorized user can cause the vehicle310to be released to continue down the assembly line300while at the same time causing the computing device100to record the information regarding the abnormality in the database. The vehicle310can then be repaired using the repair tool400by a user (who may be the same user or another user) at a later time, when the vehicle310is at any subsequent station302in the assembly line300.

One example repair tool400is a smart wrench configured to communicate with the computing device100, for example by connecting wirelessly to the network118. The wireless connection can allow the user of the repair tool400to carry it anywhere in the assembly line300in order to repair abnormalities wherever the vehicle310may be located. Like the nutrunner250, the repair tool400can include sensors that can detect the torque and angle of rotation applied when the repair tool400is used to tighten joints during the repair.

The repair tool400can also include an integrated barcode scanner to scan a barcode disposed on the vehicle310. The barcode information (representing a unique identifier for each respective vehicle310) can be sent to the computing device100to provide confirmation that the user is ready to perform a repair procedure on that particular vehicle310. Thus, receiving the barcode information can cause the computing device100to retrieve information relating to the vehicle310and the abnormality and repair instructions, and begin monitoring the repair procedure. Alternatively, a stand-alone barcode scanner in communication with the computing device100can be used to deliver barcode information to the computing device100. Other identifying tags can be disposed on the vehicle310instead of a barcode (for example, a near-field communication (NFC) tag) and read by an appropriate reader/scanner in communication with the computing device100without departing from the spirit or scope of this disclosure.

FIG. 5is a pictorial representations of a display500controlled by the computing device100, for example, via the input/output interface122. The display500can be a standalone computer monitor, or it can be a screen integrated into the repair tool400or the user's mobile device. In general, any device capable of displaying images can be used without departing from the spirit or scope of this disclosure. In addition, the information provided to the user as disclosed here can be presented in a different format, such as audio, without departing from the spirit or scope of this disclosure.

The display can be used to show an assembly line view510, which can include icons to represent the vehicles310that are currently located at each of the stations302on the assembly line300. The assembly line view510can show whether a vehicle310is flagged (i.e., has a detected abnormality) or unflagged (does not have a detected abnormality). For example, unflagged vehicles310can be represented with a green icon512while flagged vehicles310can be represented with a red icon514. In this way, the user can see at a glance where in the assembly line300the vehicles310that requires repair are currently located.

Repair instructions520can be shown on the display500to assist users with repairing abnormalities. When the user scans the barcode on the vehicle310to be repaired, the computing device100can display instructions specific to the relevant repair. In one exemplary implementation, when the computing device100receives a notification of a barcode scan, the computing device100can identify the vehicle310to be repaired and retrieve, from the database, the information regarding the abnormality associated with that vehicle310. Repair instructions520can be specific for each station302and based on the assembly process of that station302. The repair instructions520can be stored in a database (which can be but need not be the same database storing the information regarding the abnormality, discussed above) and retrieved to present to the user on the display500.

The display500can also display a diagram522containing joint labels524showing the user where the joints that need repair are located on the vehicle310and the proper sequence of how to tighten the joints (for example, the assembly process in which the abnormality occurred could have included tightening five joints in a particular sequence). The diagram522can also consist of a photograph, three-dimensional model, or other type of visual model.

The repair tool400can be configured to determine whether a joint is tightened correctly based on the torque and angle data that it captures with its sensors. For every joint that the user tightens using the repair tool400, the repair tool400can communicate to the computing device100whether the joint was tightened correctly or not. For example, the repair tool400can send either an OK message or an error message. If the computing device100receives an OK message from the repair tool400, it can update the display500to show the progress of the repair. For example, the computing device100can check off steps in the repair instructions520that are completed and/or can change the color of a completed instruction step from red to green.FIG. 5illustrates an exemplary scenario in which three out of five joints have already been successfully tightened and two joints remain to be tightened. The joint labels524on the diagram522can also be used to show which steps have been completed and which steps remain, for example by changing color from red to green. On the other hand, if the repair tool400detects an abnormality while tightening a joint (e.g., the wrong torque or a cross threading), the repair tool400can send an error indication to the computing device100which can cause the display500to show an error message.

In another exemplary implementation, the repair tool400can send raw data captured by its sensors regarding torque and angle rotation to the computing device100, and the determination whether an abnormality occurred can be made by the computing device100(rather than the repair tool400making the determination and sending an OK message or an error message to the computing device100). Other similar adaptations can be made without departing from the spirit or scope of the disclosure.

When the user has successfully completed the repair, the computing device100can display a message informing the user. In addition, the icon representing that vehicle310in the assembly line view510can change back from a red icon514to a green icon512, indicating that the vehicle310no longer requires repair. The computing device100can also remove the flag associated with the vehicle310in the database.

Turning back toFIG. 4, the repair tool400can be configured to operate using a variety of different attachment heads410. In some cases, if an assembly process (and the corresponding repair process) includes tightening several joints, it is possible that not all the joints will need the same amount of torque. In fact, using current, manual tracking methods, errors and uncorrected abnormalities are frequently found in such cases because the users performing repairs may get confused and fail to remember the proper torque for each joint. The disclosed implementations can minimize these errors. In one exemplary implementation, each attachment head410can be configured to cause the repair tool400to operate at a different torque. The repair tool400and the various attachment heads410can be configured with to communicate with each other via a short-range communication protocol such as near-field communication (NFC), Bluetooth™, or similar protocol. The repair tool400can notify the computing device100of the attachment head410that is currently attached. During a repair, the computing device100can determine, based on the repair instructions520and the specific joint that is to be tightened next, whether the correct attachment head410is attached to tighten the joint at the appropriate torque. If the attachment head410does not match the torque requirements of the joint to be tightened, then the repair tool400can be prevented from operating until the correct attachment head410is applied. The computing device100can cause the display500to display a message instructing the user to connect the appropriate attachment head410each time a different torque is needed.

The computing device100can also prevent the repair tool400from operating if the computing device100receives a barcode scan of a vehicle310which does not have any abnormality. This can ensure that the user does not inadvertently introduce an unneeded repair and potentially a new abnormality to a vehicle310that is already in suitable condition. In such a case, the computing device100can use the display500to show an error message to notify the user that the wrong vehicle310was scanned.

When the vehicle310reaches the end of the assembly line300, a check can be performed as to whether the vehicle310is still flagged (indicating that the abnormality has not yet been repaired) or whether the flag has been removed. If there is no longer a flag associated with the vehicle310, then the computing device100can allow the vehicle310to exit the assembly line300. On the other hand, if the vehicle310is still flagged, the computing device100can automatically generate a line stop command and/or issue an alert (such as by sounding an alarm or displaying an error message) indicating that the abnormality is still present in the vehicle310. The vehicle310can then be corrected at that point. A pokayoke controller200can be specially configured for the last station302of the assembly line300to implement this check and prevent the flagged vehicle310from exiting the assembly line300.

FIG. 6is a logic flowchart of an example process600for detecting an abnormality on the vehicle310. At step602, the vehicle310enters a station302on the assembly line300for an assembly procedure, for example to tighten joints. At step604, a user can use the nutrunner250to tighten the joints. As the nutrunner250tightens the joints, the attached nutrunner controller240can send torque data to the pokayoke controller200. At step606, a determination can be made, based on the data received from sensors on the nutrunner250, whether an abnormality is detected. If no, then at step608, the vehicle310can be released to the next station302in the assembly line300. If yes, then at step610, the pokayoke controller200can generate a line stop, which can halt the entire assembly line. If a line stop has been generated, a bypass command may be entered, for example, by an authorized user. At step612, the computing device100receives the bypass command entered by the authorized user. At step614, the computing device100can store information regarding the abnormality in a database including a flag associated with the vehicle310and bypass information. This information regarding the abnormality can be retrieved by the computing device100when the vehicle310is to be repaired. The process600can then return to step608, where the vehicle310can be released to the next station302in the assembly line300.

FIG. 7is a logic flowchart of an example process700for repairing an abnormality on the vehicle310. As described above, the vehicle310has been subject to a bypass command and flagged. At step702, a user scans the barcode of the vehicle310(for example, using a barcode scanner integrated into the repair tool400). At step704, the user is presented with the repair instructions520, for example, using the display500. At step706, the user performs the repair procedure, for example, to retighten the joints using the repair tool400. The computing device100can monitor the progress of the repair by the status messages received from the repair tool400after each joint is tightened. Each time the computing device100receives an indication of a successful joint tightening, the computing device100can update the display500to show the progress of the repair and show which steps of the repair instructions520have been completed and which remain. At step708, the computing device100determines whether all elements of the repair have been completed. If yes, then at step710, the flag assigned to the vehicle310can be removed, in which case the icon representing the vehicle310in the assembly line view510can also be modified to indicate that there is no flag (for example, such change can be indicated by color). If the repair has not been successfully completed, then, at step712, the vehicle310can remain flagged. Appropriate measures can be taken as warranted. For example, the user can be notified via the display500that abnormalities remain. In addition, the vehicle310can be prevented from exiting the final station302in the assembly line300or from obtaining final approval so long as the vehicle310remains flagged.

The foregoing description relates to what are presently considered to be the most practical embodiments. It is to be understood, however, that the disclosure is not to be limited to these embodiments but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. For example, the user who enters the bypass command for the vehicle310and the user who repairs the vehicle310may or may not be the same individual. In general, any portion of the disclosed devices, systems, and methods can be performed by any user without departing from the spirit and scope of the appended claims, including different users for different portions. In addition, the computing device100can be embodied in a single computer such as a server, or the instructions can be distributed among several machines (for example, several pokayoke controllers200having processing capabilities), which collectively are to be deemed the computing device100for the purpose of this disclosure. In addition, while the exemplary implementations disclosed here generally relate to tightening and torqueing procedures, the disclosed implementations can equally apply to other assembly procedures using tools appropriate for such procedures. The scope of the claims is thus to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures as is permitted under the law.