1 / 82

The Design-Methods Comparison Project

The Design-Methods Comparison Project. Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 terry@sie.arizona.edu http://www.sie.arizona.edu/sysengr/ Copyright  1998-2010 Bahill. Reference.

madison
Download Presentation

The Design-Methods Comparison Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Design-MethodsComparison Project Terry Bahill Systems and Industrial Engineering University of Arizona Tucson, AZ 85721-0020 terry@sie.arizona.edu http://www.sie.arizona.edu/sysengr/ Copyright  1998-2010 Bahill

  2. Reference Terry Bahill, Mack Alford, K. Bharathan, John Clymer, Doug Dean, Jeremy Duke, Greg Hill, Ed LaBudde, Eric Taipale, Wayne Wymore and Sten Dahlberg, The Design-Methods Comparison Project, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Vol. 28, No. 1, pp. 80-103, 1998. http://www.sie.arizona.edu/sysengr/methods2 © 2009 Bahill

  3. To a man with a hammer,everything looks like a nail.* © 2009 Bahill

  4. © 2009 Bahill

  5. Mr. Wrong Wrench © 2009 Bahill

  6. Problem statement* A farmer on a seldom-used farmroad has difficulty getting across a busy highway. Design a traffic-light system for this intersection. Normally, the highway light shall be green and the farmroad light shall be red. When a sensor signals that a tractor is on the farmroad, the highway light shall change to yellow. After a short-time interval (STI, nominally 4 seconds) the highway light shall change to red and the farmroad light shall change to green. The farmroad light shall stay green until the tractor clears the sensor or after a long-time interval (LTI, nominally 40 seconds), whichever comes first. Then the farmroad light shall become yellow. After a short time interval the farmroad light shall become red and the highway light shall become green. The system shall stay that way for a least a long time interval. After a long time interval the highway light shall be switched when the sensor detects a tractor. A timer that produces output signals after short time intervals and long time intervals will be available. It can be restarted at anytime. © 2009 Bahill

  7. The intersection © 2009 Bahill

  8. Convenient abbreviations © 2009 Bahill

  9. State transition diagram* UML: state machine diagram © 2009 Bahill

  10. State transition table dc means don’t care © 2009 Bahill

  11. Inputs and outputs © 2009 Bahill

  12. Implementation © 2009 Bahill

  13. Testing via an input/output trajectory Time runs from top to bottom © 2009 Bahill

  14. ASM chart* UML: state machine diagram © 2009 Bahill

  15. Wymorian notation1 UML: state machine diagram The traffic-light controller can be described as Z = (SZ, IZ, OZ, NZ, RZ), where /* Items enclosed with /*’s like this are comments */ /* Listing of the possible states */ SZ = {Highway-green, Highway-yellow, Farmroad-green, Farmroad-yellow} /* Listing of the four input ports and their legal values */ IZ = I1Z × I2Z × I3Z × I4Z, where © 2009 Bahill

  16. Wymorian notation2 /* Listing of the output ports and their legal values */ OZ = O1Z × O2Z × O3Z × O4Z × O5Z × O6Z × O7Z, where © 2009 Bahill

  17. Wymorian notation3* The next state function lists possible transitions between states. Each entry shows ((a present state, (an input combination)), the next state). */ NZ = {((Highway-green, (LTI + Sen))Highway-green), ((Highway-green, (LTI • Sen)), Highway-yellow), ((Highway-yellow, (STI)), Highway-yellow), ((Highway-yellow, (STI)), Farmroad-green), ((Farmroad-green, (LTI • Sen)), Farmroad-green), ((Farmroad-green, (LTI + Sen)), Farmroad-yellow), ((Farmroad-yellow, (STI)), Farmroad-yellow), ((Farmroad-yellow, (STI)), Highway-green), ((ANY-state, (Initialize)), Highway-green)}, /* The readout function lists the states and the outputs appropriate for each */ RZ = {(Highway-green, (CHWG, CFRR, Restart)), (Highway-yellow, (CHWY, CFRR, Restart)), (Farmroad-green, (CHWR, CFRG, Restart)), (Farmroad -yellow, (CHWR, CFRY, Restart))}. © 2009 Bahill

  18. Wymore’s notation © 2009 Bahill

  19. LaBudde's block definition diagram © 2009 Bahill

  20. UML: state machine diagram and timeline Mode matrix, state diagram and timeline* © 2009 Bahill

  21. Mission phases UML: block definition diagram © 2009 Bahill

  22. Operating phase scenario UML: block definition diagram © 2009 Bahill

  23. RDD-100* UML: sequence diagram © 2009 Bahill

  24. Entity relationship diagram UML: class diagram © 2009 Bahill

  25. Data flow diagram* UML: activity diagram? © 2009 Bahill

  26. State transition diagram* UML: state machine diagram © 2009 Bahill

  27. Functional decomposition UML: activity diagram © 2009 Bahill

  28. Decomposition of 1.* INIT © 2009 Bahill

  29. Decomposition of 1.1* Obtain controller hardware-OK signal* © 2009 Bahill

  30. But Object Orientated Design Functional Design © 2009 Bahill

  31. Information model UML: class diagram © 2009 Bahill

  32. State model for farmroad lights UML: state machine diagram © 2009 Bahill

  33. State model for highway lights UML: state machine diagram © 2009 Bahill

  34. Class descriptions* © 2009 Bahill

  35. Class diagram © 2009 Bahill

  36. Sequence diagram © 2009 Bahill

  37. OpEM directed graph model UML: activity diagram? © 2009 Bahill

  38. IDEF0* UML: activity diagram © 2009 Bahill

  39. Functional flow block diagrams by Sten O. Dahlberg Boeing Information, Space and Defense Systems (This solution is not in the IEEE SMC paper. It is on the web site.) © 2009 Bahill

  40. System interface diagram UML: block definition diagram © 2009 Bahill

  41. Functional interface diagram The black rectangle indicates the owner of the interface UML: block definition diagram © 2009 Bahill

  42. Who should own the interface? • COTS • Sender • especially in broadcast mode • Requirements owner • Systems engineering • DoE • Bigger • Smarter • Least flexible • Hardware • The Boss © 2009 Bahill

  43. Functional Flow Block Diagram UML: activity diagram © 2009 Bahill

  44. Operational Sequence Diagram UML: activity diagram © 2009 Bahill

  45. Assigning functionsto physical components • It’s OK to assign many functions to one physical component. • But it might be a mistake to assign one function to two components.* © 2009 Bahill

  46. Problem solving methods* Backward chaining • The medicine man has a 4-ounce bottle and a 9-ounce bottle, but I want exactly six-ounces of Kickapoo Joy Juice. • How does the medicine man meet my needs? 9 ounces 4 ounces

  47. Implementation1 • Systems engineers use high-level tools for high-level design. • Specialty design engineers implement the system. • The design may change between high-level design and low-level implementation. • We implemented 3 designs in hardware. • The design did not change for the State Transition Diagram solution. • The design did not change for Eric Taipale’s solution. © 2009 Bahill

  48. Implementation2 • The object-oriented design could not be implemented on the single-threaded operating system. • The design had to be changed significantly. • Not surprisingly, the method substantially effects the implementation. © 2009 Bahill

  49. Comparison metrics • The Traffic Light Problem had pulse outputs (Mealy machine) and level outputs (Moore machine). • All tools were able to handle this difficulty. • Another metric is complexity, quantified by the number of inputs, outputs, states and interface connections. • The distinguishing characteristic of our second problem is concurrency. © 2009 Bahill

  50. Other comparison metrics • simplicity • apparent ease of alterations • effort in learning • hand-off-ability • communicability • implementability • design changes made during implementation • ease of handling both pulse and level outputs • ease of showing all or only some transitions, outputs etc • condensability • size of documentation • scalability between large and small problems • intrusion on the designer • comprehensiveness • ease of handling concurrent processes © 2009 Bahill

More Related