Tapped Power Line Protection Engineering project

Educational Project: Complete Hardware and Software P&C Engineering Package for Tapped Power Line Protection, IEC 61850, and Hardware Specifications Project Overview We are seeking an experienced senior Protection and Control Engineer, Power Systems Engineer, or Power Systems Developer to create a comprehensive, highly detailed, end-to-end engineering package for a Tapped Power Line Protection System. The selected engineer must approach this project as a senior engineer responsible for developing a complete industrial-strength solution from initial requirements and system architecture through calculations, hardware selection, software implementation, testing, validation, documentation, and implementation guidance. The completed project is intended to become the engineering basis for a future real-world implementation. Therefore, the deliverables must go beyond a theoretical college exercise. They must demonstrate the engineering rigor, traceability, reliability, maintainability, cybersecurity awareness, redundancy, testing discipline, and documentation quality expected in an industrial Protection and Control project. At the same time, the project has an important educational purpose. I want to learn the complete process by following the work of an experienced senior engineer. Every important engineering decision must therefore be explained so that an undergraduate electrical engineering or computer engineering student can understand it. Important Scope Clarification The requirements in this description are not intended to be a complete or final list of everything required for an industrial-strength Protection and Control system. Because the purpose of this project is partly educational, I do not yet know every calculation, document, hardware component, protection function, software module, test, standard, cybersecurity control, safety requirement, or implementation step that a complete industrial project requires. The selected senior engineer is expected to identify all missing requirements and add them to the project scope. The engineer must not simply implement the items explicitly listed in this description. The engineer must evaluate the complete system, identify gaps, challenge incorrect assumptions, recommend improvements, and develop the additional engineering elements necessary to produce a coherent end-to-end design. If an important industrial requirement is missing from this description, the engineer must: * Identify the missing requirement * Explain WHAT it is * Explain WHY it is required * Explain the risk of omitting it * Recommend how it should be designed or implemented * Include it in the proposed architecture, milestone plan, or list of clearly stated exclusions * Obtain agreement before proceeding if it materially changes project cost or schedule The desired working model is similar to a junior engineer learning under the supervision of a senior engineer. I will provide the initial objectives and example requirements, while the selected senior engineer will develop the complete engineering process and explain how an experienced professional transforms an incomplete initial request into an implementation-ready project. Ultimate Goal: The Protection Architecture Playbook The final deliverable must function as a universal Protection Architecture Playbook or step-by-step engineering algorithm. After reading and following the Playbook, a student should be able to examine a blank single-line diagram and systematically develop a complete protection architecture from scratch. The Playbook must explain not only the final design, but also the senior engineer’s reasoning process: * What information must be collected first * Which questions must be asked * Which assumptions are acceptable * Which assumptions are dangerous * How missing information is handled * How protection zones are established * How protection functions are selected * How primary and backup protection are coordinated * How hardware and communication architectures are selected * How calculations are performed and independently checked * How failure modes are identified * How safety, redundancy, cybersecurity, and maintainability are addressed * How the design is tested and validated * How the project progresses from concept to implementation Educational Requirements Applying to All Deliverables Every technical document, drawing, script, calculation, configuration, and test procedure must include the following structure: WHAT: Provide a clear definition of the concept, component, calculation, configuration, or code function. WHY: Explain the engineering reason, physical theory, operational requirement, safety concern, or applicable IEEE, IEC, NEC, NERC, NPCC, utility, or manufacturer requirement driving the decision. HOW: Provide step-by-step implementation instructions, engineering calculations, mathematical derivations, configuration instructions, and verification procedures. WHAT NOT TO DO: Identify common industry mistakes, unsafe practices, incorrect assumptions, code defects, configuration problems, sizing errors, testing gaps, and design shortcuts. Explain why they fail and how to prevent them. ASSUMPTIONS AND LIMITATIONS: Clearly document all assumptions, missing input information, technical limitations, dependencies, and conditions under which the proposed solution remains valid. VERIFICATION: Explain how each important calculation, configuration, algorithm, or design decision will be independently checked. Detailed Scope and Deliverables 1. Universal Protection Architecture Playbook Create a generalized step-by-step instruction manual explaining how to start with a blank single-line diagram and develop a complete protection architecture. The Playbook must teach the exact sequence of engineering operations, including: * Collect system requirements and missing input data * Interpret the single-line diagram * Identify protected equipment * Define protection zones * Identify credible faults and abnormal operating conditions * Perform short-circuit and system studies * Select instrument transformers * Select primary and backup protection functions * Establish relay operating principles * Define breaker-failure protection * Define automatic reclosing and synchronism-check requirements * Define direct-transfer trip requirements * Develop DC control and trip circuits * Map station-bus and process-bus communication * Establish time-synchronization requirements * Define redundancy and single-failure criteria * Develop cybersecurity requirements * Develop settings and coordination procedures * Develop testing and acceptance criteria * Validate the complete architecture * Prepare construction and commissioning documentation * Establish change-control and configuration-management procedures The Playbook must be reusable for future protection projects involving different power-system architectures. 2. System Requirements and Engineering Design Basis Before beginning detailed design, develop a formal Engineering Design Basis document. It must identify: * System voltage and frequency * Line length and conductor parameters * Source configurations * Tap locations * Transformer and generator data * Grounding arrangements * Maximum and minimum fault levels * Breaker capabilities * CT and PT characteristics * Existing protection and control equipment * Communication availability * Operating philosophy * Applicable standards * Environmental conditions * Reliability targets * Maintenance requirements * Cybersecurity requirements * Utility and regulatory requirements * Missing information requiring confirmation The engineer must explain how incomplete or uncertain input data affects the design. 3. Primary and Secondary Hardware Specifications and Guide Specify suitable hardware for the tapped-line example, including: * Protection relays * Standalone Merging Units * High-Speed Tripping solid-state output modules * IEEE 1588 Precision Time Protocol grandmaster clocks * Managed industrial Ethernet switches * CTs and PTs * Test switches * Breaker auxiliary contacts * Lockout relays * DC power supplies * Battery and charger requirements * Fiber-optic components * Time-distribution equipment * Engineering workstations * Network monitoring equipment * Disturbance-recording equipment * Required panels, terminal blocks, fuses, and wiring accessories Provide concrete manufacturer and model examples from multiple established manufacturers where appropriate. Explain the engineering selection criteria and avoid creating an architecture that is unnecessarily dependent on one vendor. Provide: * Three-line AC schematics * DC control schematics * Protection schematics * Trip-circuit schematics * CT and PT wiring diagrams * Communication block diagrams * Panel-layout recommendations * Terminal plans * Cable schedules * Bill of materials * Equipment data sheets or official manufacturer links Perform: * CT ratio selection * PT ratio selection * CT burden calculations * CT saturation assessment * CT accuracy-class assessment * CT knee-point voltage calculations, where Vk must be greater than 20 times Ict when that criterion is applicable * Trip-coil burden calculations * DC voltage-drop calculations * Battery-duty calculations * Auxiliary power calculations * Breaker interrupting-duty checks Explain: * How CT saturation distorts secondary-current waveforms * How CT saturation can cause underreach, overreach, delay, or false differential current * Why conventional electromechanical relays may be too slow for demanding trip-time budgets * What happens when CT polarity is reversed * How incorrect polarity affects differential and directional protection * Why energized CT secondary circuits must never be opened * What must be verified before energization 4. Physical Cabling and Tap-Sizing Calculations Perform: * Conductor ampacity calculations * Thermal-withstand calculations using the current-squared multiplied by time relationship * Voltage-drop calculations * Short-circuit withstand calculations * Cable insulation selection * Shielding and grounding assessment * Cable-separation assessment * Fiber-link loss-budget calculations * DC control-cable sizing * Trip-circuit voltage-drop calculations Evaluate relevant NEC 240.21 tap-conductor rules and clearly explain whether and how they apply to the selected example. Clearly distinguish between transmission, distribution, industrial, utility-owned, and premises-wiring applications. Do not apply an NEC requirement outside its legitimate scope without explanation. Explain: * Why inadequately protected tap conductors can experience severe overheating, insulation failure, arcing, fire, or melting * Why protection must account for faults close to and far from the tap * Why cable routing and physical separation affect common-mode failure risk * Why grounding and shielding errors can create false relay inputs or communication failures 5. IEC 61850 Process-Bus and Station-Bus Architecture Design a fiber-optic communication architecture using Parallel Redundancy Protocol with two independent networks: * LAN A * LAN B * LC duplex fiber-optic connectors * Managed industrial Ethernet switches * Independent communication paths * Redundant power supplies * Appropriate VLAN configuration * Appropriate multicast filtering * Appropriate traffic-priority configuration * Network supervision * Time synchronization * Network-performance monitoring Explain: * Why LAN A and LAN B must remain logically and physically independent * Why incorrect PRP integration can defeat redundancy * Why unmanaged switches are inappropriate for a controlled industrial process-bus design * How loops, broadcast storms, multicast flooding, congestion, and incorrect VLAN configuration affect protection performance * Why fiber routing, bend radius, connector cleanliness, labeling, testing, and physical segregation matter * How network failures are detected and reported * How the architecture behaves during any single network or switch failure 6. IEC 61850 System Configuration and SCD File Generator Develop a clean, fully commented Python script that programmatically generates a valid Substation Configuration Description file. The generated SCD file must include appropriately structured elements for: * Substation * Voltage levels * Bays * Conducting equipment * Communication * Connected access points * GSE * Sampled Values * IEDs * Access points * Logical devices * Logical nodes * Data sets * GOOSE control blocks * Sampled Value control blocks * Report control blocks where applicable The generated file must be validated using an appropriate XML schema or another documented validation method. Explain: * The hierarchy of IEC 61850 System Configuration Language files * The purposes of ICD, CID, SCD, SSD, and related SCL file types * How IED capability information becomes part of the engineered configuration * Why GOOSE APPIDs must be unique and controlled * Why VLAN identifiers and priorities must be engineered consistently * Why Priority 4 may be selected for time-critical GOOSE traffic in this example * Why GOOSE traffic must not be treated like ordinary HTTP or TCP traffic * How congestion and incorrect switch configuration produce unpredictable delay * Which naming, namespace, and schema mistakes commonly invalidate SCL files * How configuration revisions are controlled and audited 7. Distance Protection Engine, ANSI 21, with Infeed Logic Implement an educational real-time distance-protection algorithm in Python or C++. The algorithm must include: * Voltage and current phasor estimation * Frequency tracking * Filtering * Apparent impedance calculation * Directional supervision * Zone 1, Zone 2, and Zone 3 logic * Configurable operating characteristics * Fault-loop selection * Phase-to-phase fault calculations * Phase-to-ground fault calculations * Zero-sequence compensation * Dynamic infeed compensation * Fault-resistance considerations * Load-encroachment logic * Power-swing considerations * Trip timing * Event logging * Blocking and restraint logic * Clearly documented numerical assumptions Use the following project relationship for infeed compensation: Z true equals Z apparent divided by the quantity one plus I infeed divided by I tap. The assumptions, valid operating conditions, and limitations of this relationship must be explicitly explained and tested. If a more technically correct or robust method is required, the senior engineer must propose and justify it. Integrate second-harmonic restraint at 120 Hz for a 60 Hz system to reduce false operation during relevant inrush conditions. The threshold must be configurable, with a default test threshold of 15 percent. Explain: * Why downstream infeed can cause distance-protection underreach * Why the relay may perceive a fault as farther away than its physical location * How source impedance affects apparent impedance * How fault resistance affects reach * Why second-harmonic content is associated with transformer inrush * Why harmonic restraint must not be applied blindly to every protection function * How dependable tripping and secure blocking are balanced * Why a production algorithm requires deterministic execution, extensive validation, cybersecurity controls, and independent review 8. Real-Time Operating-System Tuning and Automation Deliver a fully commented Bash configuration script for PREEMPT_RT Linux. The script must demonstrate how to: * Isolate CPU cores using isolcpus * Configure CPU affinity * Assign real-time priorities using SCHED_FIFO priority 99 * Configure interrupt affinity * Optimize network ring buffers * Reduce avoidable operating-system jitter * Lock memory where applicable * Configure and monitor ptp4l * Verify microsecond-level clock synchronization * Log configuration and timing results * Restore or roll back changes safely The script must include permission checks, validation checks, warnings, error handling, and safe defaults. Explain: * Operating-system context switching * Kernel preemption * Scheduling and trip latency * Why standard Linux can introduce timing jitter * Why critical threads should not share unisolated cores with uncontrolled workloads * How interrupts and background services affect deterministic execution * Why SCHED_FIFO priority 99 can starve essential processes if used incorrectly * Why PTP synchronization accuracy must be measured rather than assumed 9. Automated COMTRADE PyTest Harness and FAT Plan Develop a Python PyTest suite that parses IEEE C37.111 COMTRADE files and performs automated fault-injection sweeps. The test framework must support: * COMTRADE configuration files * ASCII data files * Binary data files * Analog channels * Digital channels * Multiple sampling rates where practical * Fault-inception-angle sweeps * Fault-location sweeps * Fault-resistance sweeps * Infeed-ratio sweeps * Harmonic-content sweeps * Trip and no-trip assertions * Trip-time measurement * Pass and fail reporting * Repeatable execution * Machine-readable results Provide a detailed Factory Acceptance Test matrix covering: * Normal operation * Internal and external faults * Communication failures * Time-synchronization failures * CT and PT failures * Hardware failures * Power-supply failures * Network redundancy failures * Protection-algorithm edge cases * Incorrect configuration * Recovery after failure * Cybersecurity-related events * Performance and latency testing Explain: * How COMTRADE represents sampled analog and digital information * How configuration files define channels, scaling, timing, and format * How binary COMTRADE files store samples * How trip timing is verified programmatically * How expected results are established * Why manual button-push testing alone is inadequate * Why automated testing does not eliminate independent engineering review and physical FAT * How incomplete or unrealistic test data can create false confidence 10. Industrial Engineering Completeness Review The senior engineer must perform a formal gap analysis comparing the proposed project against the requirements of a complete industrial Protection and Control implementation. The review must identify any additional required items, including: * Short-circuit studies * Protection coordination studies * Grounding studies * Insulation-coordination studies * Reliability analysis * Failure Modes and Effects Analysis * Single-point-of-failure analysis * Cybersecurity risk assessment * Network traffic and loading studies * DC system studies * Panel and wiring design * Settings-management procedures * Configuration-management procedures * Quality-assurance procedures * Construction packages * Commissioning procedures * Maintenance procedures * Training requirements * Regulatory approvals * Utility approvals * Professional engineering reviews Items that cannot be completed because project-specific data is unavailable must be clearly identified as open requirements, not silently omitted. Acceptance Criteria and Definition of Done Criterion 1: Universal Playbook Usability The documentation must function as a generalized, step-by-step instruction manual enabling a student to develop a protection architecture from scratch. Criterion 2: Educational Clarity All documentation and code comments must be accessible to an undergraduate engineering student. Every major section must explicitly contain WHAT, WHY, HOW, WHAT NOT TO DO, ASSUMPTIONS AND LIMITATIONS, and VERIFICATION guidance. Criterion 3: End-to-End Completeness The deliverables must form one coherent end-to-end engineering package rather than a collection of disconnected calculations and scripts. The architecture, hardware, schematics, settings, communication design, software, test cases, and implementation procedures must be mutually consistent and traceable. Criterion 4: End-to-End Latency Target The execution path from Sampled Value packet intake to GOOSE trip publication must be demonstrated to execute in 3.0 milliseconds or less under documented test conditions. The engineer must document: * Test hardware * Operating-system configuration * Network configuration * Traffic conditions * Number of test samples * Measurement method * Clock source * Maximum latency * Average latency * Percentile latency * Jitter * Reproducibility limitations Criterion 5: Hardware and Code Validation All calculation spreadsheets must be fully derived, documented, independently checked, and verified. All delivered scripts, including the SCD generator, COMTRADE test bench, relay algorithm, and Linux configuration tools, must run successfully using the documented environment and installation procedure. Criterion 6: Infeed and Restraint Verification The ANSI 21 algorithm must correctly estimate fault distance across the documented range of downstream-infeed ratios. The algorithm must refrain from tripping during specified inrush scenarios when second-harmonic content exceeds the configured 15 percent threshold. Criterion 7: Reproducibility The contractor must provide: * Source code * Dependency files * Installation instructions * Example input data * Example output data * Test procedures * Expected results * Hardware data sheets or official manufacturer links * Software and firmware versions * Assumptions and limitations * Troubleshooting instructions * Revision history * Traceability between requirements, design, implementation, and testing Criterion 8: Senior Engineering Gap Analysis The engineer must identify requirements missing from this description and explain how each gap should be resolved. Simply delivering only the explicitly listed items without evaluating overall industrial completeness will not satisfy the project requirements. Criterion 9: Implementation Readiness The final package must provide a clear path from educational prototype to real-world implementation. It must identify: * Which components are educational demonstrations * Which components are suitable as an engineering basis * Which items require site-specific data * Which items require manufacturer-specific testing * Which items require utility approval * Which items require review and sealing by a licensed Professional Engineer * Which tests must be repeated using production hardware * Which remaining risks must be resolved before energization Safety and Professional Engineering Limitation Although the final package is intended to support a future real-world implementation, educational code and example calculations must not be installed directly in an energized utility or industrial power system without site-specific engineering. Any implementation must undergo independent review, system studies, hardware-in-the-loop testing, Factory Acceptance Testing, Site Acceptance Testing, commissioning, utility approval, and approval by qualified and appropriately licensed Protection and Control engineers. Required Skills and Qualifications Domain Expertise: * Power System Protection and Control * Substation automation * Distance protection * CT and PT sizing * Protection coordination * Tapped-line protection * NEC interpretation * IEC 61850 engineering * Digital-substation networking * Industrial control-system cybersecurity * Testing and commissioning Teaching and Technical-Writing Ability: The contractor must be able to explain complex electrical and software engineering concepts clearly and translate senior engineering knowledge into repeatable, step-by-step procedures. Standards and Technologies: * IEC 61850-8-1 GOOSE * IEC 61850-9-2 Sampled Values * IEC 61850 SCL and SCD * IEEE C37.111 COMTRADE * IEEE 1588 Precision Time Protocol * ANSI protection functions 21, 50, 51, 67, 79, 87, and 50BF * Parallel Redundancy Protocol * Relevant NEC requirements * Relevant utility, NERC, NPCC, IEEE, and cybersecurity requirements Software: * Python 3 * NumPy * PyTest * lxml * C++17 or C++20 where applicable * Linux PREEMPT_RT * Bash * Wireshark * XML and SCL validation tools * Git or another source-control system * Appropriate power-system study and relay-testing tools How to Apply Please submit a proposal containing: * Examples of technical writing, educational engineering tutorials, or Protection and Control projects you have created * A description of your industrial Protection and Control experience * Your experience with IEC 61850, protection algorithms, COMTRADE, and real-time Linux * Your proposed system-development approach * Your proposed fixed-price breakdown by milestone * Your estimated completion timeline * The software and hardware tools you plan to use * The standards and references you plan to follow * Your method for validating the 3.0-millisecond latency target * Your approach for identifying requirements missing from this description * Any assumptions, exclusions, risks, or technical concerns you identify * A clear distinction between what will be fully delivered and what will remain dependent on site-specific information