System Level Design

Team Vision for System-Level Design Phase

During this phase, the team planned to finish the following activities:

• Functional Decomposition
• Benchmarking
• Morphological Chart
• Selection Criteria
• Pugh Chart
• Final Concept Selection
• Feasibility
• System Architecture
• Risk Assessment

During the execution of this phase, the team finished all planned activities as well as acquiring all of the parts for the project from the MSD Floor where it had been stored over the summer semester. 

Functional Decomposition

Document Owner: Jeffrey Seamon

Date Updated: 9/25/2020

Function Tree:

Transformation Diagram:

Benchmarking

Concept Development

Steven's Initial Concept Generation (ICG):

Function 1: LRH Partitioning and Playback

• Allow user to select additional notes to add/remove from auto-play
• Identify 'lines' of music to separate into two different portions e.g. a line is a unbroken line of notes within 1 octave of the previous
• Implement machine intelligence to judge LRH parts in MIDI files
• Hard-fix LRH positioning
• Have user manually select which 'lines' to play or not
• Separate LRH by clef
• Automatic human tempo response measures
• Piano 'nudges' the player back onto beat by delaying play
• Improvisational note playing to any notes being played
• Piano fills in incomplete notes from user

Function 2: MIDI Handling

• Update to MIDI 2.0
• Add redundancy measures to note transmission
• Add anti-corruption measures to note transmission
• MIDI file access and download for user
• Have config permissions for whether any user can access music bank
• Internet connection for open-source MIDI bank
• MIDI File music suggest to multiple users
• Live note editing
• Allow user to create custom MIDI songs
• Internet backup for MIDI files

Nick's ICG:

Function 1: Determining Feedback Input

Function 2: Display Feedback to User

Functions	1	2	3	4
Software Language
UI display
Method of playback	Using a Guitar Hero style of showing what notes were played		System generated report	Automated piano playback

Jeff's ICG:

David's ICG:

Feedback System:

User Control:

Josiah's ICG:

Function 1: UI/Intuitive Controls

			facial recognition
mobile/app	olden days website (retro vibes)	ancient scroll (antique vibes for the mozart lovers)	oral tradition (for our blind pianists)
Python	HTML	calligraphy	linguistics will help us design an intuitive, spoken-word device

Function 2: Transcription System

Feasibility: Prototyping, Analysis, Simulation

CE System Level Review

• UI Planning and Design
  
  • Will develop and poll several different versions of user interfaces to determine best intuitive response. (What UI planning scheme operates best in providing an intuitively understandable application that any user can manage?)
    
  • Which of our concepts (morphological chart) for the "playing" UI suit the customer/player? Can we implement this reasonably? (Decide which displays MIDI the most effectively.)
    
• Feedback System
  • Will benchmark different speeds of sensor data transfer between optical, laser, button, and recorded (How quick of a turnaround is it to display live feedback to the user achievable by button-decoding? Optical sensing? Microphone-AI-Decoding?)
    
• Song Playback
  
  • What is the longest song that can be played due to storage limitations of the RaspberryPi control system? (Determine what errors would occur from elongated MIDI file buffering/constraints on the RaspberryPi in handling large file sizes)
    

  • How long of a delay should exist between when a person finishes selecting a song/attributes and when the count-in/song starts playing? (Analysis - Measure average times to move hands to move to piano keys from UI, look into allowing users to select delay times.)

EE System Level Review

• Solenoid Powering
  
  • How much power will the solenoid array require to sustain 10 actuation's at once?
• Sustain Pedal Powering
  • How much power is required to operate the sustain pedal in addition to up to 10 key presses?
• Printed Circuit Boards
  
  • Are the MOSFET's working correctly, or will additional insulation or replacement of parts be needed?
    

ME System Level Review

• Solenoid Performance
  • Can the solenoid noise be reduced by adding gaskets to the inner cylinder? (Test the solenoid with various gaskets/o-rings to see how quiet they can be without slowing the solenoids.)
  • Will our piano sound as good as a regular player piano? How about a MIDI virtual keyboard? A human player? (Compare the same song being played on each)

• Sustain Pedal

  • What is the best way to mount the sustain pedal actuator to the piano without modifying the piano? (Prototyping - Use cardboard, foam, masking tape, etc. to develop simple models that mock potential attachment designs and locations.)

Morphological Chart and Concept Selection

Document Owner: Nick Besley

Date Created: 9/16/2020

Functions	1	2	3	4	5	6
Feedback Module/Sensors	Contact microphone	Vibration Sensor	Microphone	Laser/Optical	Infrared	Button (designed)
Volume Calibration	Microphone	Vibration Sensor	Accelerometer
Noise Dampening	Vacuum Chamber	Foam	Gaskets (planned)
Pedal Actuation	Wormgear	Linear actuator
Key-playing Mechanism	Electric Solenoids (in place)	Pneumatic Solenoids	Hydraulic Solenoid Valves
User Interface	Touch Screen	Hardware Knobs/Buttons	Mobile App	Website	Mind controller	Voice control
Providing power (Consolidated power supply)	1 36 V Supply, 1 5 V supply (in place)	Single consolidated power supply	Batteries	Small module reactor
Software Platform	Raspberry Pi 3 w/ Teensy (in place)	Microcontroller	Arduino
Solenoid Controller Boards	Bus Connection	PWM Adafruit Board	Microcontroller	Custom Built Board (designed)
Programming Language	Python	C++	Javascript	For Neural Networks	C
Signal Transfer Medium	Copper Wires (in place)	Bluetooth	Fiber optics	Laser
Mounting System	Stainless Steel Rails (in place)	Suspended	Zipties	Velcro
Circuit Board Mounting System	Shelf	Suspended	Zipties	Velcro	Stainless Steel Rails (in place)
Method of playback	Using a Guitar Hero style of showing what notes were played	Audio playback	System generated report	Automated piano playback	Vertical Piano Roll - well known, but will not be intuitively above each note	Direct to Paper Representation - a callback to the previous forms of player pianos, but virtually useless to read
Feedback Sensor Mounting Location	On strings	Under Keys	On Hammer Connectors	On Top of Keys

System Construction Chart

Concept Selection

Selection Criteria

Based on the team's Customer and Engineering Requirements the selection criteria was designed such that it covers everything required by the customer. The Concept Selection Criteria Table below shows the selection criteria that was developed. After several iterations, this is the group of criteria that the team determined would cover the ERs and CRs the most completely as well as the most concise to make selection not too complex and bloated from too finely detailed selection criteria.

Concept Selection Criteria Table

System Construction and Comparison

The team went through and evaluated the current system based on the technical paper the previous team handed off for us as well as individual system assessment (EE System, CE System, ME System) such that we compare the current state of the system, what previous teams have designed, with any small or minor improvements that could potentially be made. Because of this, the current system design was used as our datum for our detailed systems comparison which was done below the Pugh chart here. Once detailed design was completed and the results populated the chart below, the final system was able to be selected. If there were any designs that had an overall improvement over the existing design then this is where that would be determined. If the totals below each column representing the systems we designed showed a positive number then that would indicate that the design was determined to adhere to our selection criteria better. As seen in the table, this was not the case so no major improvements were determined to be needed for this implementation. 

Pugh Chart 

In Depth System Comparison

Here the team took their respective system designs and compared them more in detail to the datum, which was determined to be the baseline as mentioned previously. If the selection criteria determined System A's function was better than System B's function, then a '-' is marked in the table. If the selection criteria favored System B, then a '+' is marked in the table. If both systems' function choice evaluated equally based on the selection criteria then a '=' is marked. To determine the totals seen in the Pugh chart above, the magnitudes were added up where a '-' is counted as -1, a '+' is counted as +1 and a '=' is counted as 0. With this, the totals at the bottom relating to each selection criteria were then populated into the Pugh Chart above. 

Document Owner: Jeffrey Seamon

Date Created: 9/25/2020

Document Owner: Steven Petrick

Date Created: 9/25/20

Document Owner: Josiah Martuscello

Date Created: 9/25/20

Document Owner: David Anthony

Date Created: 9/25/20

Final System Selections

Based on the results of the Pugh Chart regarding the detailed systems comparison as mentioned earlier, the final system that will be designed further in detail during the next phase can be seen below in the table. This was determined by our selection criteria to fulfill our requirements the best. Note that most of the decisions that were made were to keep the current system that had been designed by previous teams with minor improvements coming mainly in the circuit board mounting system with adding shelves for circuits to sit upon. Note that as a part of our design, a linear actuator will be used to activate the sustain pedal which is not currently implemented. 

Standards

Standards are sparse and far between for the scope of the project. The project doesn't have any outstanding features for any standards grant applications with the possible exception of the piano being categorized as an assistive medical technology. This will have to be followed up upon as the system design.

List of Standards for Consideration:

82079-1-2019 - IEEE/IEC International Standard for Preparation of information for use (instructions for use) of products - Part 1: Principles and general requirements

Providing a standard of use to the end-customer should start to be developed and laid out in a manner as standardize

IEC PNW 72-1245 Automatic electrical controls -Part 2-XX: Particular requirements for current sensing controls

The project could shift into the aspect of sensors for the feedback system which will likely dominated our design strategies so any standards on such should be read up upon

1857-2013 - IEEE Standard for Advanced Audio and Video Coding

Standards for compressing and decompressing audio to save bandwidth. Relevant to audio files being transmitted via IP, such as uploading or downloading music, or sending audio recordings to be processed on a web server.

IEEE Standard for Advanced Audio and Video Coding," in IEEE Std 1857-2013 , vol., no., pp.1-178, 4 June 2013, doi: 10.1109/IEEESTD.2013.6522104 https://ieeexplore.ieee.org/document/6522104

26514-2010 - IEEE Standard for Adoption of ISO/IEC 26514:2008 Systems and Software Engineering--Requirements for Designers and Developers of User Documentation

The team will be developing user documentation for the project, and as such should follow relevant standards.

IEEE Standard for Adoption of ISO/IEC 26514:2008 Systems and Software Engineering--Requirements for Designers and Developers of User Documentation," in IEEE Std 26514-2010 , vol., no., pp.1-72, 27 Jan. 2011, doi: 10.1109/IEEESTD.2011.5712775. https://ieeexplore.ieee.org/document/5712775

ISO/IEC JTC 1/SC 35 - User interfaces

Standards for user interfaces to allow accessibility and adaptability, as well as navigation.

ISO 19353:2019 - ISO Standard for Safety of machinery — Fire prevention and fire protection

Our project involves the use of solenoids, which can heat up, and many electrical components in and around an old wooden piano, which could pose a fire risk. This standard could help us minimize this risk

MIL-DTL-4040G - Military Specification: General Specification for Electrical Solenoid

Military standard on the general requirements for solenoids, which we will be using many in our project.

Systems Architecture

Our system's inputs consist of the UI display and controller, the key presses by a human pianist, and the power supplied to the system. When operating the system, the pianist uses the UI to select the song and related playing criteria. The Raspberry Pi will then process the midi file of the chosen song into a matrix which is used to manage the PWM signal. The matrix data is used to communicate with the solenoid Controller Board from the Raspberry Pi and based on the matrix information, different pulse signals are sent by the PWM board to control the solenoids and push the keys. If the feedback module is used, the pianist will use the UI to indicate that and prep the system to record data The user will then play the piano while the system is collecting data using feedback sensors to record the key-presses. The raw data is converted to digital data via Microcontroller before saving it to Raspberry Pi. Once, the user select done on the touch screen, the Raspberry Pi will process the data into a midi file. Then, the user can choose the newly created midi file to be play.

Risk Assessment

The following link leads to the risk management sheet that compiles the template filled with several risks assessed and categorized for the project.

Risk Management Sheet on Google Docs

System Level Design Review - 10/5/2020

See the System Level Design Review Notes sub-page for more information

The following link leads to the pre-read of the review: System Level Design Review Pre-read. A PDF version is available here.

The following link leads to the presentation given for the Problem Definition Review: System Level Design Review Presentation. A PDF version is available here.

Plans for next phase

Team Plans for Next Phase:

The Preliminary Detailed Design stage involves the open-ended familiarization of the physical modules that compose the player piano. By utilizing the implementation left from the previous team, this phase allows the team to prepare for precise design procedures and tasks to be accomplished in the following phases. The team will begin prototyping and constructing initial design of the final implementation of the system. The system modules, both existing and planned, will be thoroughly tested to ensure functional compliance. These steps prepare the team, functionally and conceptually, to continue into the actual Detailed Design phase.

Individual Three-Week Plans:

David Anthony End of SLD Phase Three-Week Plan

Nick Besley End of SLD Phase Three-Week Plan

Josiah Martuscello End of SLD Phase Three-Week Plan

Steven Petrick End of SLD Phase Three-Week Plan

Jeffrey Seamon End of SLD Phase Three-Week Plan