BMW Set to Shake Up The EV Charging Market with Portable Charger

In the never-ending quest to expand charging mechanisms that help validate the EV value proposition, BMW has announced a new hi-rate ‘suitcase sized’ charging unit, to ease the current pain associated with availability of plug-in points. According to BMW N.A.’s Robert Healey Manager for EV Infrastructure, “Our focus is on getting as many DC fast chargers out there as possible, but the cost has been a hindrance. We want to remove every perceived barrier for our potential customers. We want to ensure that customers see these chargers.”

While news of a portable hi-charge system rollout is undoubtedly helpful, the new product is more than just a proprietary charging system, but also offers charging support to major brands beyond the BMW logo including; Ford, GM and Volkswagen. “We don’t want to own infrastructure,” said Cliff Fietzek, BMW’s Manager of Connected eMobility. “We want to support the rollout (of EV’s) and we’re heavily supporting partnerships, but we don’t want to be the network operator like Tesla, for example.”

Along with the ready availability of charging for a host of EV products, the new charging program offers a significantly discounted price point. Currently, hi-rate charging systems can cost as much as $30k per copy while BMW’s new portable unit will only set customers back $6,500.

Using tests with the BMW i3 lithium-ion batteries, the new system can produce an 80% charge in about 30 minutes, based on its 24-kilowatt power pack. Along with its speed the package is quite compact and only weighs 100 pounds, versus the typically 1500 pound variant. This advantage alone will make installation and utilization much more efficient than current charging types.

The product is set to launch the beginning of August, and nearly 285 out of 340 BMW iDealers have already signed up to offer the new system.

Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. These are proposed by any Ethereum community member and then discussed internally.

Only after you fully understand the connection between EIPs and ERCs can you understand how ERCs work. So, first things first.

EIP types

Before diving in to what EIP status means, you ought to understand what the purpose of each EIP type is and why there’s a wide variety of them.

Standard Track: This describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum.
Core: This refers to improvements requiring a consensus fork (such as EIP5 and EIP101) as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the miner/node strategy changes 2, 3, and 4 of EIP86).
Networking: This includes improvements around devp2p (EIP8) and the Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of Whisper and Swarm.
Interface: This refers to improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP6) and contract ABIs. The label “interface” aligns with the interface’s repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
ERC: These are application-level standards and conventions, including contract standards such as token standards (ERC20), name registries (ERC137), URI schemes (ERC681), library/package formats (EIP190), and wallet formats (EIP85).
Meta: This describes a process surrounding Ethereum or which proposes a change to (or an event in) a process. Process EIPs are like Standard Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum’s codebase. They often require community consensus. Unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any Meta EIP is also considered a Process EIP.
Informational: This type of EIP describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to either ignore Informational EIPs or follow their advice.

EIP status terms

There’s plenty to understand if you would like to fully grasp which EIPs are implemented, which ERCs are incorporated on each, and, of course, which ones are final and live. The most important EIP statuses are:

Draft – an EIP that is open for consideration and is undergoing rapid iteration and changes.
Last Call – an EIP that is done with its initial iteration and ready for review by a wide audience.
Accepted – a core EIP that has been in Last Call for at least two weeks and any technical changes that were requested have been addressed by the author. The process for core devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to Final.
Final (non-Core) – an EIP that has been in Last Call for at least two weeks and any technical changes that were requested have been addressed by the author.
Final (Core) – an EIP that the core devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
Deferred – an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.

In the next guide, I’ll look into different ERCs, how they work, there purpose, and the multiple types of standards there are and how they can be used.