Mistake Proofing Software Requirements Document I/O Test

Transcription

1 Mistake Proofing Software Requirements Document I/O Test Owner: Nima Bayan Page 1 of 16 Revision: 3.1

2 TABLE OF CONTENTS 1 INTRODUCTION DOCUMENT PURPOSE INTENDED USERS SUPPORTING DOCUMENTATION SRD FOR LIGHT TEST PHASE I WinCE MicroLogix PHASE II WinCE...Error! Bookmark not defined MicroLogix...Error! Bookmark not defined. 2.3 PHASE III...ERROR! BOOKMARK NOT DEFINED WinCE MicroLogix PHASE III, NAVIGATION & SCREEN MOCK-UPS MP DECISION MAKING MATRIX FOR NEW DEVELOPMENT WINCE SOLUTION ULGX BASED SOLUTION MATRIX PHASE I CONFIGURATION VALUES ENABLING OUTPUT LIGHT TESTING FEATURE SETTING UP ON/OFF DURATION TIMERS LIGHT TESTING PROCEDURE PHASE II CONFIGURATION VALUES (TBD)...14 Owner: Nima Bayan Page 2 of 16 Revision: 3.1

3 Document Revision History Date Revision Number Name 2006 Sep Nima Bayan First draft Description (include pages affected) 2006 Sep Marcus Sternberg Format standardized per APICS current document template 2006 Sep Nima Bayan Revised per results of AME contract and internal developers meetings; developing in two (2) phases July David Wu Add window design for lights test 2008 Feb Alan Hanselman Change Daimler to Chrysler logo Owner: Nima Bayan Page 3 of 16 Revision: 3.1

4 1 INTRODUCTION 1.1 Document Purpose This document was developed to provide a guideline for the software design for the Mistake Proofing Project 1.2 Intended Users Software developers Administrative/clerical personnel Technical writers 1.3 Supporting Documentation The Chrysler documents listed below are instrumental in defining Mistake Proofing. The user should have a good understanding of these documents. Doc. No. Rev. Date Title 1.4 Nomenclature ulgx: MicroLogix 1200 (small Allen-Bradley PLC) WinCE: Mistake Proofing Windows CE based SBC SBC: Single Board Computer I/O: Input/Output PLC: Programmable Logic Controller LED: Light Emitting Diode PFCS: Plant Floor Communication Systems WCC: WorkCell Controller Owner: Nima Bayan Page 4 of 16 Revision: 3.1

5 2 SRD FOR LIGHT TEST 2.1 Phase I This phase is an intermediary phase that would be implemented in MicroLogix (ulgx) PLC only. It would make the verification of output lights possible. Note, it is assumed that this option (upon enabling) is only executed at initialization, i.e. at start-up and the line is NOT running WinCE No change is necessary at this phase MicroLogix A change will be made to the existing code to provide light test at the start up. This light test will be: With configurable enable, i.e. using a configuration bit (N13:14/4) one can enable the initialization routine which performs an automatic, sequential light test. Sequential, meaning each light (ulgx output) would be turned on (default of 1.2 seconds) and then off (default of 0.3 seconds) for a configurable, sensible period, and then the next output would be tested, etc. ulgx Code Rev No code would be developed for testing inputs as this can easily be accomplished by observing the input card s indicating LED s. Also, Two versions of this code will be released one for 16 I/O case and the other for 32 I/O boxes. It is decided that due to safety issues this configuration is not populated in standard release code. This is due to the fact that some of these MP boxes are connected to torque tools and we do not want any sudden tool activation. 2.2 Phase II This phase would be implemented in WinCE Application only. It would make the verification of output lights possible using a new screen. Note, it is assumed that this option is only executed when the associated assembly line is NOT running, or in other words the station is not sequencing and we are not waiting for a download from PFCS WCC WinCE A change will be made to the existing application to provide light test screen for the users. This is a modal screen i.e. the user should close the screen to get out and while on the screen other screens are not active. Accessing the screen This light test screen will be: Owner: Nima Bayan Page 5 of 16 Revision: 3.1

6 Accessed via the configuration screen, via a go to screen button. Possibility of adding LDAP authentication at this stage is to be investigate we need to answer the following questions: Does a device with Static IP on PA need LDAP user authentication for specific tasks? And what are they (is the any corporate level description for floor devices password protections)? What is the process of getting authentication for such a device? (IPR,...) What if the device has already passed the original IPR (w/o LDAP Authentication)? Are there any canned applications that developers can use? If the answer is YES, which platforms (e.g. Java,...)? Are there anything available for Embedded platforms (esp. WinCE 4.0.2)? Is the existing process (Java Applet) scalable to WinCE (i.e. what are the platform requirement e.g. JVM,...)? What is the process that ACC guys had to go through to complete the LDAP authentication? Contact name? Are there any certifications necessary? If yes who has documentation, knows the process? While on the screen There will be (32) momentary push-buttons on this new screen and their (32) associated pick-status indicators. Pushing each soft-button would send a corresponding pick message to ulgx. Pushing each real-input button would also change the corresponding pick-status indicator on the screen to green, also the green pilot light on the stack-light would light up. (To be discussed and decided first) Also a Test All In Sequence would enable the user to initiate the test in sequence (as provided by phase I). Exiting the screen Upon exiting this screen (pressing the close buttons (one is the standard Windows X-button and the other is provided by us) an all clear signal (a download of all zeros) would be made to the ulgx to clear all outstanding outputs. Pressing cancel button would send the control and the view back to Configuration screen. A real down-load would nullify the screen and automatically send the command (and the current view) to the Main screen. (the possibility and detail to be discussed first) Owner: Nima Bayan Page 6 of 16 Revision: 3.1

7 2.2.2 MicroLogix (To be discussed and decided first) Test All in Sequence ability is implemented by making an existing bit that would latch (N13:14/4) bit and start the operations as described in (To be discussed and decided first) A new header code identifier and program would be implemented to accommodate Phase II. On the basis of the header identifier, and a mapped output command coming from the WinCE, ulgx would turn the desired output on. (Also, when the associated input is pressed the output would be turned off and the green acknowledge light would turn on too, i.e. the rest is handled like a real download) 2.3 Phase II, Navigation & Screen Mock-ups Configuration Screen Mock-up Figure 2-1 Addition of new I/O test (go to screen) button to Configuration Screen Owner: Nima Bayan Page 7 of 16 Revision: 3.1

8 Figure 2-2 Proposed layout of new I/O test button Screen Owner: Nima Bayan Page 8 of 16 Revision: 3.1

9 3 MP DECISION MAKING MATRIX FOR NEW DEVELOPMENT The ranking is done on a scale of 0-10; 10 being the most preferred and 0 meaning the least attractive. Both solutions involve coding 3.1 WinCE solution Involves developing a new screen in WinCE App. Coding in MicroLogix (ulgx) and changing the header information in the existing protocol. 3.2 ulgx based solution Involves start-up (initialization) logic development for light testing 3.3 Matrix Engineering Design Impleme-ntaion Testing Plant Launch % 50% 10% 20% Solution Expandability (1) Flexibility (2) End User Friendliness (3) Corporate Standard (4) Risk (5) Time (6) Cost (7) 1 WinCE Based ulgx Based Matrix column notes 1 Proposed system ability to grow on functionality and tasks if needed (higher values assigned to expandable solution) 2 Ability to use the development for other purposes 3 Plant operator friendliness of logic and interface (higher values are assigned to intuitive solutions or the ones that do not involve other support people e.g. Electricians) 4 Related to existing architecture and follows standards that may be found in the BOIG. 5 Possible effect on existing applications and/or affecting production. 6 The shorter the time the better (10= up to 1 Week; 1= more than one months) 7 The lower the costs the better (Lower costs get higher marks). Directly related to hours put into project. 8 Internal resources engagement, less engagement is preferred due to availability of HR for other tasks (10= less engaging; 1= Very engaging) 9 Plant resources to be able to install the system without outside support (favorable) 10 Each main category is individually divided by the group maximum 11 Weighted average calculated as: Normalized Average * Weight 12 Overall Average Percentage Resources (8) Time Cost (7) Resources (8) Time Cost (7) Resources (9) Total Points (Linear Summation) Normalized Average (10) Weighted Average (%) (11) Overall Normalized Result (%) (12) Owner: Nima Bayan Page 9 of 16 Revision: 3.1

10 4 PHASE I CONFIGURATION VALUES 4.1 Enabling Output Light Testing Feature To enable output light testing feature, configuration bit N13:14/4 shall be set in initialization. for the mistake proofing option. This is accomplished as shown in Figure 3 in Ladder file 12- OEM_CONFIG. Figure 3 Enabling output light testing feature 4.2 Setting Up ON/OFF Duration Timers Timers T4:6 and T4:7 preset values determine the output lights ON-OFF duration respectively. As system timers they re configured in initialization Ladder logic file 4-INIT. This is accomplished as shown in Figure 4 in rungs 0013 and Values shown in this figure are default and can be changed based on application. Note: Have in mind that timer preset values would directly affect proper operation of the logic by delaying it for [No. of Outputs*( T4:6.PRE + T4:7.PRE)] seconds! For example if the Mistake Proofing box has 16 outputs this operation would take over one minute to finish, hence delays proper box operation for that 64 seconds (=16*(3+1)). Owner: Nima Bayan Page 10 of 16 Revision: 3.1

11 Figure 4 Setting ON/OFF Duration Timers Owner: Nima Bayan Page 11 of 16 Revision: 3.1

12 5 LIGHT TESTING PROCEDURE Whenever any output button gets click, an On data related to corresponding output will be sent to MicroLogix. Then the corresponding light status will be required by WinCE. The light status will be displayed on testing window. When that output button gets click again, an Off data related to corresponding output will be sent to MicroLogix. The corresponding light status will be displayed on testing window as well. When the Test All In Sequence button gets click, the an output data from On to Off which will last about 30 seconds will be sent to MicroLogix for each corresponding output sequentially. The lights status will be required and displayed on the testing window. The processing flowchart is shown in figure 5. Owner: Nima Bayan Page 12 of 16 Revision: 3.1

13 MP I/O Test Processing Flowchart any key click? yes no close? individual test? test all? yes yes back to main window no Odd? N=0 send OFF data to specified light yes send ON data to specified light no N<32? request corresponding light status from PLC request corresponding light status from PLC yes send ON data to light N display light status on testing window display light status on testing window request light status from PLC back to testing window display light status on testing window time delay 30 seconds send OFF data to light N request light status from PLC display light sttaus on testing window N=N+1 Owner: Nima Bayan Page 13 of 16 Revision: 3.1

14 6. Phase II Configuration Values (NA) Owner: Nima Bayan Page 14 of 16 Revision: 3.1

15 Owner: Nima Bayan Page 15 of 16 Revision: 3.1

16 Owner: Nima Bayan Page 16 of 16 Revision: 3.1