Engineering
Engineering
Battery Engineering That Starts With Your Requirements, Not Our Catalog
There is a version of battery engineering that amounts to selecting off-the-shelf cells, integrating them with a commodity BMS board, and putting the assembly in a standard enclosure. That approach works for simple applications with generous performance margins and no particular requirement for reliability, longevity, or regulatory compliance. For everything else, you need actual engineering.
The Pulsar Industries engineering team has designed battery systems for underground mining vehicles where a thermal runaway event would be catastrophic, for transit buses that cycle twice daily in Texas summers and could not fail mid-route, and for industrial forklifts running three-shift operations where downtime measured in minutes translated to production losses measured in thousands of dollars. That background shapes how we approach every battery engineering program — with the same rigor whether the application is a residential backup system or a commercial energy storage installation.
Requirements and Concept Definition
The single most valuable investment in a battery development program is a thorough requirements definition at the beginning. Requirements that are vague, incomplete, or unchallenged at Phase 1 become expensive problems at every subsequent phase. Our requirements definition process covers system energy and power requirements, operating voltage and current ranges, charge and discharge rate profiles, operating and storage temperature ranges, mechanical constraints (dimensions, weight, mounting, enclosure class), communication and control interface requirements, expected cycle life and calendar life, regulatory certifications required, and cost targets. The output is a requirements document that becomes the engineering reference for the entire program. Every design decision is evaluated against these requirements. Every prototype test is structured to validate performance against them. If requirements change — and they sometimes do — the change is documented and the downstream implications are evaluated explicitly.
System Architecture and Detailed Design
With a complete requirements document, we develop the system architecture. This covers cell chemistry selection and format selection (cylindrical, prismatic, pouch), pack configuration (series and parallel cell arrangement to achieve the required voltage and capacity), module design, mechanical enclosure design, thermal management approach (passive cooling, forced air, liquid cooling, or heating where required by low-temperature operation), BMS hardware selection or design, BMS firmware architecture, and electrical system integration including communication interfaces. Where the application has demanding thermal, structural, or electrical requirements, we run simulation work before hardware is built. Thermal finite element analysis predicts temperature distribution throughout the pack under the expected load profile and worst-case ambient conditions. Structural analysis validates enclosure design against vibration spectra and shock loads. Electrical modeling validates the performance predictions against the requirements. The cost of finding problems in simulation is small. The cost of finding them in hardware is large.
Prototype Build and Validation
The first prototype is built in our Texas facility using production-representative components wherever possible. This is a deliberate design decision. A prototype built with hand-selected, best-in-lot components gives you a misleadingly optimistic picture of production performance. We build with production-representative components from the first unit, so that the performance we measure in validation testing is the performance we expect to see in production. Validation testing covers electrical performance (capacity, efficiency, charge and discharge curves across the voltage and temperature range), thermal performance under representative load profiles, BMS function verification (protection thresholds, balancing behavior, state-of-charge estimation accuracy), communication interface verification, mechanical abuse testing (vibration, shock, drop), and initial safety testing against the relevant standards. Every test is documented against the requirements, and any gap is addressed before moving to the next phase.
Production Transition
Moving a validated prototype into production without losing quality and consistency requires careful management of the production transition. Assembly procedures must be documented in sufficient detail that any trained assembler can produce the same result. Tooling and fixtures must be designed to constrain the assembly process to the correct procedure. Incoming inspection criteria must be established for every critical component. End-of-line test specifications must be defined. Production readiness review gates must verify that all of these elements are in place before production begins. Pulsar Industries manages this transition explicitly, with formal production readiness reviews at defined milestones and a structured first-article inspection process for the initial production units. The goal is a production system that delivers consistent, specification-compliant products from the very first unit — not a system that requires several months of production learning to stabilize.
CAPABILITIES
Engineering Capabilities
- Cell selection and qualification (LFP, NMC, NCA, LTO, and other chemistries)
- Battery module and pack mechanical design using 3D CAD
- Battery Management System hardware design
- BMS firmware development — we own the source code on all systems we develop
- Thermal finite element analysis and thermal management system design
- Structural and vibration analysis
- Communication protocol development: CAN, RS485, Modbus, proprietary
- Electrical system integration and harness design
- Regulatory test planning and coordination: UL, CE, UN38.3, ISO
- Production tooling design and assembly procedure documentation
FAQ
Frequently Asked Question
Do you own the firmware source code on systems you develop?
Yes, for all systems we develop and manufacture ourselves, we own the firmware source code outright. For custom client programs, ownership of the source code is negotiated as part of the engagement agreement and depends on the program structure.
Can you take on a partial program — for example, just the BMS development?
Yes. We frequently engage as specialists on specific engineering challenges within a larger program. BMS development, thermal analysis, and compliance test strategy are common standalone engagements.
What is your experience with automotive-grade requirements?
Our team has experience with IATF 16949 quality management systems, automotive FMEA, APQP processes, and the elevated reliability and traceability requirements of automotive applications from the Voltabox AG era.