BQ76952 :parallel connections

Normally the 10p cells would be welded together and monitored with a single bq76952 for the entire 16s10p pack.  Then the voltage on all "cell-1" cells are at the same voltage, all "cell-2" voltages are the same, etc., so it isn't necessary to separately monitor each parallel cell voltage.  You can also have multiple thermistors attached to several different places on the pack without needing separate bq76952 devices.  However, if you want to monitor the current separately on each 1p stack, and if you want separate FETs for each 1p stack, then you may need this configuration.  Here it seems you intend to have each "pack" be 16s1p, and you will then connect the 10 packs in parallel.  This requires thinking through several facets of the system, I can briefly comment on them here.

Config - are the packs all connected at manufacturing, then not changed for the life of the product?  Or do you intended to have packs swapped out later in the field, when they may be at different state of charge?

Power - do you expect to include CHG/DSG FETs in each pack?  If you intend to connect packs at a later time, and each new pack might be at a different state of charge vs the rest, then you have to carefully control when FETs are turned on, to avoid uncontrolled charging of a lower voltage pack by a higher voltage pack, while still allowing power supplied to the load by the highest voltage pack initially, until higher voltage packs discharge to the voltage of the lowest voltage pack.  Charging also has to be done carefully, so the lowest voltage pack will be charged first.

Comms and control - if you do not include a separate uC in each pack, you can assign a different I2C address to each bq76952, then communicate with each separately on a common I2C bus from an external host.  If you include a local uC in each pack, then the comms would be from the uC to a host, which then depends on what comm protocol and physical layer you are using.  The bq76952 does not support a daisy chain communication structure, so the comms would either need to be star-connected back to a host, or a daisy-chain configuration could be implemented using the local uC in each pack.

Thanks,

Terry

Do you plan on the insertion of additional parallel packs occurring in the field (while installed and in use) or in your factory, in a controlled environment before being shipped out?

For comms, you cannot easily share a single SPI bus among multiple parts (maybe by having a separate CS line from the host for each pack), so this would be a star configuration.  For I2C you can also have a star configuration with every pack having the same address, but you then cannot share a single bus.  For a single bus, if you are assembling the packs in your factory, you can program each to a different I2C address on your assembly line - this can be programmed into the OTP on each device.  But if these slave packs will be bought and installed by an end user, this probably won't be practical without having a uC in each slave pack to handle some type of bus negotiation and autoaddressing scheme.

If you do not have a common gnd line between the separate packs, then you will need some type of level shifting or isolation solution between them.  TI has a portfolio of digital signal isolators that you can browse at https://www.ti.com/isolation/digital-isolators/products.html.  

For uncontrolled charging/discharging, you will probably need your master device to manage this.  For example, assume someone installs a high voltage (HV) pack and a low voltage (LV) pack together.  Your master will tell both packs to enable their DSG FETs but keep their CHG FETs disabled.  The HV pack will supply the load current, and the HV-CHG FET will turn on due to body diode protection (assuming series FETs).  As the HV pack discharges near the voltage of the LV pack, the LV pack will eventually be supplying load current, so its LV-CHG FET will be enabled by body diode protection.

Then if a charger is attached, your master will need to disable the HV-DSG FET, keeping the LV-DSG FET enabled to support any load.  Then the master can enable the LV-CHG and HV-CHG FETs, allowing charging current to first flow into the LV pack and charge it up.  The LV-DSG FET will turn on due to body diode protection.  As the LV pack charges to the voltage of the HV pack, then HV-CHG FET will have current flow as well, so the HV-DSG FET would then turn on by body diode protection.

If the charger is removed, the HV body diode protection stops, causing the HV-DSG FET to be disabled. Load current may start flowing through the LV-DSG FET.  The master then will send a command to disable the LV-CHG FET (but it may stay on due to body diode protection), then the master also disables the HV-CHG FET and enables the HV-DSG FET.  At this point, the HV pack will begin supporting the load current, and the LV-CHG FET will be disabled when its body diode protection ends. 

This is just a quick view, but there are many details you have to consider in this type case.  You can see this takes careful control by the master, I don't think the BQ76952 can handle it all autonomously, except that each device can have its local protection enabled, to disable its CHG FET whenever an excessive chg current occurs, if the HV pack were to start charging the LV pack.  I doubt you want to rely on this for normal operation, though, this would primarily be the fallback protection for a failure in normal operation.

I would recommend using the comms for the master to control the FETs in the other packs.  if you use the DFETOFF, CFETOFF pins, these will override the body diode protection, which you probably do not want in your case.  Your master needs to know when a load is attached vs a charger is attached, and decide how to reconfigure things quickly.  So you may need to make sure you can detect those events (such as the ALERT pin from each pack getting back to the master).