This is a useful [white]paper in the sense that it has everything in one place, but the disgusting overuse of "software-defined" means I had to overcome a fully

This is a useful [white]paper in the sense that it has everything in one place, but the disgusting overuse of "software-defined" means I had to overcome a fully pegged internal B.S. meter while trying to read it. What I mean is: surely a "software-defined" battery would be some kind of redox/flow battery where you can literally adjust the physical properties of the battery to suit the current SOC and current/anticipated system demands. Don't get me wrong, we need more work like this, particularly if Tesla powerwall home batteries and the like are going to become a thing that we don't want filling landfills with avoidable charge/discharge cycles. But wow, SDx. I mean, SDR is obvious; software-defined radios clearly replace fixed hardware with programmable IFs and tonnes of DSP. Similarly, networks can be software-defined if they replace discrete stand-alone equipment with fewer tiers of more capable hardware delineated more by connectivity/performance than function. When it comes to this paper though, nothing is being replaced. And again, it's useful work, particularly in the context of consumer applications (cf. aerospace which has already had to produce systems that do funky, adaptive, predictive, cooperative load/charge management across multiple battery chemistries). I don't know what I'm saying. It's an interesting paper, but as someone working on low-power systems and exploring different battery chemistries for different things, the whole SDx angle somehow cheapens it... but perhaps I'm just weird.