To satisfy /ohm/ challenge 01 – build a switching power supply
To create an heirloom project something that should last 100 years
A general piece of control equipment that can be duplicated many times.
To be built to modern standards and safety requirements
The power supply shall meet or exceed the requirements of UL61010-2-201
The power supply shall not service NEC Class 2 circuits.
The power supply shall meet additional Jordan Waughtal requirements.
The power supply shall consist of at least distinct 3 parts
Input Line Filter/Protection/Conditioning Network
Isolated Flyback 40V nominal output supply
Buck Converter to Final Output Voltage
(Optional) Power control/measurement circuit
Power supply shall operate on a wide input voltage range 80-300VAC. (Jordan)
Power supply shall not exceed 15A while operating at 120VAC. (Jordan)
Power supply shall output 40A while at 12V. (Jordan)
Power supply output shall be floating. (Jordan)
Power supply output shall continue to operate if either (+) or (-) is connected to earth. (Jordan)
Power supply shall continue to operate after an input power interruption of at least 3 line cycles (Jordan)
Power supply shall continue to operate after a 300% voltage swell for at least 1 line cycle. (Jordan)
Power supply shall have over current protection. (Jordan)
Power supply output shall have an over voltage protection crowbar circuit. (Jordan)
Power supply shall have output indicator. (Jordan)
Power supply shall have input indicator. (Jordan)
Power supply shall have over current protection indicator. (Jordan)
Power supply intermediate power circuits shall have an indicator. (Jordan)
Power supply shall have a manual output on/off switch. (Jordan)
Power supply output shall shall limit damage to the output buck converter circuit from misapplication of input power voltage. (Jordan)
Power supply shall be designed to last 100 years (Jordan)
Power supply shall operate at temperatures from 32°F to 125°F (Jordan)
Power supply shall be undamaged from storage temperatures from -40°F to 180°F (Jordan)
Power supply shall have efficiency of at least 70% (Jordan)
Include system interface diagrams here if needed, especially in systems with complex communication busses. Suppose the communication or external interfacing is complex (but necessary). In that case, it’s okay to reference an external document with details (e.g., “System shall interface with product Omega per document Omega Link Unified Language”). Remember to put any references in the appendix.
What type of constraints on personnel, operators, or other users does the system need? (e.g., does the system require special training, or do the users require ESD protection or similar?)
Where does the user interact with the system (e.g., a particular station or area)?
Who will maintain the system? What type of training or skills do they need?
How often does the system need maintenance? How long does maintenance
Does the system need modifications to allow maintenance (e.g., an access panel)?
How much downtime is acceptable? Are there any considerations to redundant systems during downtime?
This section might use statistics to specify requirements (e.g., 99% uptime, 80% capacity over ten years, etc.)
Failure Mode and Effects Analysis and a detailed quality plan often govern more in-depth reliability planning; reference them in the appendix if using them.
What sort of governing quality standards or plans does the system use? Are there internal quality specifications (e.g., company policy) or external specifications (e.g., IPC, ISO, etc.) in use?
If the system has multiple modes, use a flowchart, state diagram, or similar to describe the operations and how the user (or system) switches between these modes.
How large is the memory, storage space, or bandwidth (for software)?
Does the system require standard “off-the-shelf” parts, or is it acceptable to use custom fabrication?
Remember to use ranges or tolerances as necessary. Also, avoid over-specifying requirements if they aren’t the principal consideration. For example, a system might require a specific construction material or just require the system to weigh under a specific amount.
How does the system grow in the future or accommodate expanded use (e.g., more users, increased bandwidth, physical throughput, etc.)?
How does the system change when it reaches the limits of its use (e.g., adding more systems in parallel, expanding the existing system’s capabilities, etc.)?
How does the system change when utilized less than expected?
General environmental considerations are temperature, water, dust, heat, physical shock, mold, salt, radiation, chemicals, pressure, wildlife, humans, etc. These elements will vary depending on the system’s environment. Environment also includes non-physical economic/social requirements. You can also specify a standard, such as IP testing, to govern a specific water/dust requirement.
How do you secure the system, either physically or through software?
What sort of authentication does the user need to operate the system (e.g., keys, passwords, building access, etc.)?
What kind of protection does the system have against tampering/sabotage/accidental user error?
How does the system report any security violations (e.g., software logs, physical breaks when a panel opens, alarms, etc.)?
What are the methods of securing software code (e.g., Git methodology, CI/CD branch testing, pen-testing, disconnecting network access during system failure)?
What is the storage method for information about the system (e.g., schematics, software code, industrial diagrams, market research information, etc.)?
What health and safety regulations surround the system’s operation (e.g., OSHA Lockout/Tagout, internal company safety procedures, etc.)?
Who will monitor and buy spare parts for the system? Where will you store spare parts or specific tools?
Does shipment or transport require special certification(e.g., UN 38.3 for batteries)?
What type of materials should you use to package the system (e.g., ESD-safe plastic, JEDEC trays, wooden crates, waterproof containers, etc.)?
How will you store the system intermittently? Does storage require a particular environment (e.g., refrigeration)?
The easiest way to write this section is to reference the specific test plan that governs the system (e.g., “System shall be considered successful when it passes all tests described in…”).
An easy way to write a test plan is to go back through the requirements, look for any “shall” requirements, and then quantify them in a test procedure. If you wrote the requirements document correctly, all requirement items have a singular testable condition with clearly-defined acceptance criteria.
For items that aren’t objectively testable but require judgment, specify a person, title, or position of whoever shall qualify that item.
Again, you can simply put all of this information in a separate test plan and then reference the test plan.