methods
1 GW
So...
Sitting here in the morning with an empty stomach and a grouchy outlook....
(as opposed to viewing the problem with a wide angle lens)
It looks like I need to review the system architecture and estimate how much more it will cost to support funny business.... then eliminate said funny-business.
Funny business examples:
Contactors that run off System Voltage.
You see these a lot in Golf Carts and other systems which were originally 48V max and slowly grew to big for their britches. It results in non COTS components that, ... unless they are adopted... will have LEGACY SUPPLY ISSUES once the manufacturer stops requesting them from the supplier. (READ THAT AGAIN - THAT IS NOT WHAT WE ARE AFTER - COTS IS HOW WE ROLL)
You also see this in "all in one" solutions... like the Sevcon controller... where the controller over-reaches into other sub-systems and assumes it is the only important component in the system. No Isolated CAN, all peripherals run off 1/2 Batt Voltage referenced to Ground... It controls the contactor.... to play nice with controllers like this requires either duplication of componentry or severely encumbering system integration. We do not wish to duplicate components where possible and we certainly do not want to "build into" other sub-systems if we can help it.
Component-centric design is a major focal point...
What component does your design revolve around?
Whatever component it is... that component ends up over-reaching and ... doing things poorly... that a dedicated subsystem would do better.
In some designs I have reviewed multiple components end up being overly centric... in an attempt to avoid needing other subsystems. The Controller and BMS may reach too far... resulting in all sorts of sorrow including scaling issues.
Maintaining strict boundaries in a system architecture may increase costs and complexity a bit... but the payoff comes later.
Where we are going is standardizing these interfaces so offerings from multiple companies can play nice together.
The OPPOSITE of this is compacting a system further and further... until the motor is packed full of controller and the battery is forced to be near the controller... this does not scale
Standard communications (CAN is what it will be)
Standards of isolation (overly burdensome in a low voltage application but obvious in a high voltage)
Agreement on best practices for critical safety systems (this is where you focus super high quality standards on a very small part of the system so you can go willy-nilly in other parts of the system)
Ok... eggs on the table...
-methods
Sitting here in the morning with an empty stomach and a grouchy outlook....
(as opposed to viewing the problem with a wide angle lens)
It looks like I need to review the system architecture and estimate how much more it will cost to support funny business.... then eliminate said funny-business.
Funny business examples:
Contactors that run off System Voltage.
You see these a lot in Golf Carts and other systems which were originally 48V max and slowly grew to big for their britches. It results in non COTS components that, ... unless they are adopted... will have LEGACY SUPPLY ISSUES once the manufacturer stops requesting them from the supplier. (READ THAT AGAIN - THAT IS NOT WHAT WE ARE AFTER - COTS IS HOW WE ROLL)
You also see this in "all in one" solutions... like the Sevcon controller... where the controller over-reaches into other sub-systems and assumes it is the only important component in the system. No Isolated CAN, all peripherals run off 1/2 Batt Voltage referenced to Ground... It controls the contactor.... to play nice with controllers like this requires either duplication of componentry or severely encumbering system integration. We do not wish to duplicate components where possible and we certainly do not want to "build into" other sub-systems if we can help it.
Component-centric design is a major focal point...
What component does your design revolve around?
Whatever component it is... that component ends up over-reaching and ... doing things poorly... that a dedicated subsystem would do better.
In some designs I have reviewed multiple components end up being overly centric... in an attempt to avoid needing other subsystems. The Controller and BMS may reach too far... resulting in all sorts of sorrow including scaling issues.
Maintaining strict boundaries in a system architecture may increase costs and complexity a bit... but the payoff comes later.
Where we are going is standardizing these interfaces so offerings from multiple companies can play nice together.
The OPPOSITE of this is compacting a system further and further... until the motor is packed full of controller and the battery is forced to be near the controller... this does not scale
Standard communications (CAN is what it will be)
Standards of isolation (overly burdensome in a low voltage application but obvious in a high voltage)
Agreement on best practices for critical safety systems (this is where you focus super high quality standards on a very small part of the system so you can go willy-nilly in other parts of the system)
Ok... eggs on the table...
-methods