The specs linked by
@balazer go into far more detail than consumers need to know, they are spelled out primarily for equipment manufacturers to ensure consistent product functionality.
One item worth noting, this spec is dated 2010, which is prior to adoption of CCS (which was in draft form at the time and ratified in 2012). Initially, DC charging was described using the J1772 plug and socket, but was relatively low powered (80A maybe?). Thus CCS eventually specified separate terminals for DC power transfer. However, this item (5.5 in the document) is interesting:
5.5 Digital Data Transfer
A duty cycle of 5% indicates that digital communication is required and must be established between the EVSE and vehicle before charging. This is required for DC charging. Digital communication is optional at any valid control pilot duty cycle for AC Level 1 & 2 charging. When optionally used with AC Level 1 & 2 charging, more functions may be accommodated than by Control Pilot duty cycle functionality alone. Digital data transfer is currently under development (read this to mean ISO15118/CCS protocol development).
What this indicates is, J1772 specs were ratified with CCS DCFC in mind, though not yet completed. The same control pilot circuit defines the duty cycle requirements to trigger the EV to invoke digital communications needed for DCFC.
As has been discussed elsewhere, the ISO15118 Specs outline communications for CCS charging, but the ISO15118 specs also apply (optionally) for AC charging using J1772 couplers. In subsequent ISO15118 specification standards, Vehicle to X, and Plug & Charge (secure method with digital certificates) were defined. Therefore, mechanisms are in place for enabling both V2X and P&C functionality on both AC and DC charging. The keyword is the optional clause in both J1772 and ISO15118 specs, and few, if any AC charging equipment makers, nor OEMs, have pursued this option, but they could! Similarly, none have pursued DC charging on the J1772 coupler.
BTW, Tesla has followed J1772 communications specs for AC charging since their first mass produced EV (Model S in 2012), thus enabling their cars and AC chargers to work on any EV that is equipped with J1772 or Tesla sockets. This allowed for adapters because of the common communications protocols. However, in V3 Tesla AC chargers, they added optional capabilities for digital communications for Tesla vehicles only, and for billing purposes. While this is an optional provisioning step, it is primarily only used when billing is intended, and Tesla will only provision billing for sites with 6+ AC destination chargers, and only if the site host requests it. Therefore, Tesla V3 AC chargers remain compatible with J1772 EVs by default. A final word on this, the provisioning can also be performed to limit AC charging to Tesla vehicles only, or for specific Tesla vehicles without adding billing capabilities. This is accomplished similar to a MAC address filter, the unique vehicle ID has to conform to a pattern to authorize charging. Tesla Tap claims to have built a bridging capability into their adapters allowing J1772 EVs to appear as a generic Tesla EV, but not comply with the requirements for the specific Tesla, or billing schemes.
Because Tesla has adopted the ISO15118 stack in newer models, and offers a retrofit for older models to use CCS, it is conceivable AC billing could be modified in future firmware releases allowing all EVs to use Tesla AC chargers and be automatically billed by Tesla. Or, this could be done side by side with native Tesla protocols for legacy Tesla EVs that don't support CCS like they are doing on the DCFC Supercharger network.
Digging a bit deeper into the billing aspects. Tesla "Plug&Charge" is effectively the same as CCS AutoCharge. I know Plug&Charge is a confusing topic, because it is used to describe both the certificate based ISO15118 P&C, as well as AutoCharge. In the original CCS specs from 2012, provisions were made to allow vehicles to share their unique ID with the charger. This could be MAC address for the charging port, or VIN, but in either case, this identifier is unique and thus can be used to link the car to a billing account on the charging network's systems. While this identifier is nearly universally implemented on both native CCS equipped EVs (VW group may not comply???), it is also implemented in the ISO15118 stack on Tesla cars. Evidence of Tesla complying is that CCS compatible Teslas can enroll in EVGo's Autocharge+ the same as most CCS equipped EVs. While Autocharge lacks the security of a certificate and TLS encrypted session, it is simple to implement and could be easily done on both AC and DC Tesla chargers if Tesla is willing to do so.
Because AutoCharge lacks security, it is unlikely to be the long term Plug&Charge method. But, since J1772 is included in the ISO15118 stack, it is conceivable ISO15118 P&C with certificates could be implemented universally, on AC and DC chargers, over J1772, CCS, or NACS plugs and sockets. AutoCharge is a more universal implementation of plug & charge in that it requires minimal computing due to the lack of certificates and not using the optional asymmetrical encryption that is required for ISO15118 P&C. But most new EVs are being designed with ISO15118 P&C capabilities in mind, so over time it should become the dominant billing method.
My take on the proximity overlap, the Control Pilot pin detects the presence of an EV being connected to start the duty cycle signaling. The Proximity Pilot serves a different function, detecting when the plug is fully engaged and safe to send energy over the power pins to the car. Thus, when the lever on a J1772 or CCS plug is pressed, the circuit is opened to stop the flow of energy before the plug can be removed. Failing to do so could result in arcing with relatively high voltages and currents being passed to the car, resulting in personal or equipment damage. In other words, the PP functions as a safety measure while the CP is only concerned with signaling. No doubt there is a linkage between the proximity detection as the Control Pilot will signal to the EVSE to stop sending energy (end the session) when the PP is opened.
