WEBVTT NOTE This file was exported by MacCaption version 7.0.06 to comply with the WebVTT specification dated March 27, 2017. 00:00:20.542 --> 00:00:25.458 align:center line:-1 position:50% size:73% Hello, and welcome to Lesson Six of Keysight's EV and EVSE Charging Test Boot Camp. 00:00:25.458 --> 00:00:28.625 align:center line:-1 position:50% size:49% In this lesson, you'll hear once again from Jens Schmutzler. 00:00:28.625 --> 00:00:33.667 align:center line:-1 position:50% size:54% He has covered Testing and Test Control Notation Version 3, or TTCN-3, 00:00:33.667 --> 00:00:36.500 align:center line:-1 position:50% size:43% and how this powerful standardized testing technology 00:00:36.500 --> 00:00:38.875 align:center line:-1 position:50% size:26% is used in a vehicle to create testing. 00:00:38.875 --> 00:00:42.208 align:center line:-1 position:50% size:52% He also walks us through the definition of authentification profiles 00:00:42.208 --> 00:00:48.667 align:center line:-1 position:50% size:58% using ISO 15118 communication standards essential for securing EV charging. 00:00:48.667 --> 00:00:55.083 align:center line:-1 position:50% size:66% If you have a look at the DIN 70122 or ISO 15118 -4 and -5 conformance test standards, 00:00:55.083 --> 00:01:02.250 align:center line:-1 position:50% size:64% you will see that they employ Testing and Test Control Notation Version 3, or TTCN-3, 00:01:02.250 --> 00:01:07.792 align:center line:-1 position:50% size:50% as the standardized test specification and implementation language. 00:01:07.792 --> 00:01:11.167 align:center line:-1 position:50% size:35% This standard is basically defined by ETSI, 00:01:11.167 --> 00:01:15.875 align:center line:-1 position:50% size:46% the European Telecommunications Standards Institute. 00:01:15.875 --> 00:01:25.333 align:center line:-1 position:50% size:68% TTCN-3 describes test specifications which can be used for white box, gray box, or black box tests. 00:01:25.333 --> 00:01:29.417 align:center line:-1 position:50% size:54% It is typically used for conformance but can also be used for functional tests, 00:01:29.417 --> 00:01:36.667 align:center line:-1 position:50% size:65% scalability tests, robustness tests, and can be used from unit up to integration tests 00:01:36.667 --> 00:01:40.417 align:center line:-1 position:50% size:26% and validation tests or end-of-line tests. 00:01:42.000 --> 00:01:47.667 align:center line:-1 position:50% size:47% TTCN-3 is widely adopted in the telecommunications domain. 00:01:47.667 --> 00:01:56.042 align:center line:-1 position:50% size:64% It has quite a long history in telecommunications for ISDN, GSM, UMTS, LTE, 00:01:56.042 --> 00:02:01.375 align:center line:-1 position:50% size:38% but up to 5G and even 6G developments. 00:02:01.375 --> 00:02:09.125 align:center line:-1 position:50% size:66% It is increasingly also getting traction in the automotive domain for automotive Ethernet 00:02:09.125 --> 00:02:16.875 align:center line:-1 position:50% size:54% for most AUTOSAR, but also in the area of ISO 15118 and DIN 70121. 00:02:19.375 --> 00:02:26.875 align:center line:-1 position:50% size:65% Why did we decide to utilize TTCN-3 for the CCS charging communication standards? 00:02:26.875 --> 00:02:31.083 align:center line:-1 position:50% size:48% It's a standardized test specification and test implementation language 00:02:31.083 --> 00:02:34.750 align:center line:-1 position:50% size:49% and even provides a standardized XML Schema binding 00:02:34.750 --> 00:02:42.458 align:center line:-1 position:50% size:70% which becomes relevant for the coding of messages because ISO 15118 and DIN 70121 00:02:42.458 --> 00:02:50.333 align:center line:-1 position:50% size:49% are based on XML schema grammar than coding in EXI. 00:02:50.333 --> 00:02:56.042 align:center line:-1 position:50% size:38% This type of schema binding in TTCN-3 is very beneficial 00:02:56.042 --> 00:03:01.167 align:center line:-1 position:50% size:31% to a formal verification and validation concept. 00:03:01.167 --> 00:03:05.000 align:center line:-1 position:50% size:62% It furthermore provides a template mechanism for matching of message. 00:03:05.000 --> 00:03:07.500 align:center line:-1 position:50% size:29% For data-driven tests, this is very handy 00:03:07.500 --> 00:03:13.333 align:center line:-1 position:50% size:43% and it also provides the concept of verdict and verdict building. 00:03:13.333 --> 00:03:19.250 align:center line:-1 position:50% size:48% Overall, using or leveraging TTCN-3 allows, actually, to define 00:03:19.250 --> 00:03:25.542 align:center line:-1 position:50% size:60% the test cases programmatically not only in a human-readable tabular format, 00:03:25.542 --> 00:03:28.042 align:center line:-1 position:50% size:39% but reading programmatically 00:03:28.042 --> 00:03:33.208 align:center line:-1 position:50% size:49% without ending up in a vendor lock-in for a particular toolchain. 00:03:36.042 --> 00:03:42.417 align:center line:-1 position:50% size:55% Now let's look into the test architecture reference model according to ISO 15118. 00:03:42.417 --> 00:03:46.458 align:center line:-1 position:50% size:37% It is based on the paradigm of black box testing. 00:03:46.458 --> 00:03:50.208 align:center line:-1 position:50% size:54% That means that we are connecting the test system to the system under test 00:03:50.208 --> 00:03:54.458 align:center line:-1 position:50% size:34% only through the interface that is also being tested. 00:03:54.458 --> 00:04:01.875 align:center line:-1 position:50% size:69% There's no further interface established between the test system and the system under test. 00:04:01.875 --> 00:04:09.375 align:center line:-1 position:50% size:69% On the other end, we have then the actual test case specification provided in TTCN-3 source code. 00:04:09.375 --> 00:04:16.917 align:center line:-1 position:50% size:48% That is forming the actual test suite deployed inside the test framework. 00:04:16.917 --> 00:04:21.167 align:center line:-1 position:50% size:49% Then, we have a set of codecs which are responsible for translating 00:04:21.167 --> 00:04:25.583 align:center line:-1 position:50% size:42% from the TTCN-3 data structure into the target data structure 00:04:25.583 --> 00:04:28.458 align:center line:-1 position:50% size:34% that is being understood by the system under test. 00:04:28.458 --> 00:04:37.833 align:center line:-1 position:50% size:62% In our case, it is the Efficient XML Interchange grammar for the V2G methods schema. 00:04:37.833 --> 00:04:44.208 align:center line:-1 position:50% size:59% We then have the SDP protocol grammar, we have the V2G transfer protocol grammar, 00:04:44.208 --> 00:04:53.125 align:center line:-1 position:50% size:70% and the SLAC messages for the association process according to (unintelligible). 00:04:53.125 --> 00:04:56.708 align:center line:-1 position:50% size:44% Then we have the adapter plane 00:04:56.708 --> 00:05:02.542 align:center line:-1 position:50% size:52% which is responsible for the connection to the system under test. 00:05:02.542 --> 00:05:09.875 align:center line:-1 position:50% size:42% As an example, for the 61851-1 system under test adapter, 00:05:09.875 --> 00:05:16.583 align:center line:-1 position:50% size:62% there is a message-based exchange pattern between the test system and this SUT adapter 00:05:16.583 --> 00:05:25.083 align:center line:-1 position:50% size:51% which is then, in turn, being translated into an actual PWM signal 00:05:25.083 --> 00:05:30.125 align:center line:-1 position:50% size:47% over the control pilot line according to the CCS specification. 00:05:30.125 --> 00:05:33.875 align:center line:-1 position:50% size:35% Now, how does the actual test execution look like? 00:05:33.875 --> 00:05:38.917 align:center line:-1 position:50% size:56% The test system in the first step sends a stimulus to the system under test 00:05:38.917 --> 00:05:42.375 align:center line:-1 position:50% size:42% and then waits for the response from the system under test. 00:05:42.375 --> 00:05:48.375 align:center line:-1 position:50% size:45% As soon as this arrives, it matches basically the response 00:05:48.375 --> 00:05:56.000 align:center line:-1 position:50% size:54% to the expected template it has available and then builds a verdict 00:05:56.000 --> 00:06:00.000 align:center line:-1 position:50% size:33% based on the outcome of the matching process. 00:06:02.917 --> 00:06:07.500 align:center line:-1 position:50% size:57% How this test architecture reference model is mapped to a real-world test system, 00:06:07.500 --> 00:06:10.750 align:center line:-1 position:50% size:41% in this case, the Keysight CDS you can see on this slide. 00:06:10.750 --> 00:06:16.625 align:center line:-1 position:50% size:51% The Keysight CDS is being used here as the test adapter hardware 00:06:16.625 --> 00:06:19.750 align:center line:-1 position:50% size:36% which is directly connected to the system under test. 00:06:19.750 --> 00:06:25.958 align:center line:-1 position:50% size:49% It provides all the physical means to interact with the system under test 00:06:25.958 --> 00:06:35.125 align:center line:-1 position:50% size:67% both in terms of charging communications or provides basic PLC communication capabilities, 00:06:35.125 --> 00:06:39.875 align:center line:-1 position:50% size:52% the control pilot line signaling, and, of course, also the power transfer 00:06:39.875 --> 00:06:42.125 align:center line:-1 position:50% size:47% and the corresponding power units. 00:06:42.125 --> 00:06:47.250 align:center line:-1 position:50% size:40% We then have the test system which executes or provides 00:06:47.250 --> 00:06:51.083 align:center line:-1 position:50% size:53% all the functionality as described before in the test architecture reference model 00:06:51.083 --> 00:06:55.708 align:center line:-1 position:50% size:36% and, then, we have added value functionalities 00:06:55.708 --> 00:06:59.500 align:center line:-1 position:50% size:37% depending on the actual test system implementation 00:06:59.500 --> 00:07:04.083 align:center line:-1 position:50% size:65% for test suite management, test case extensions, test parameter management, 00:07:04.083 --> 00:07:05.958 align:center line:-1 position:50% size:43% and test execution management 00:07:05.958 --> 00:07:10.042 align:center line:-1 position:50% size:43% and, of course, really important, logging facilities 00:07:10.042 --> 00:07:14.792 align:center line:-1 position:50% size:44% and corresponding test reporting which is then, at the end, 00:07:14.792 --> 00:07:22.583 align:center line:-1 position:50% size:58% relevant for potential certification processes or for communicating all the types of errors 00:07:22.583 --> 00:07:27.625 align:center line:-1 position:50% size:48% found to the customer or to the development departments. 00:07:29.958 --> 00:07:38.875 align:center line:-1 position:50% size:60% Now, let's look into one particular topic on the authentication principles in ISO 15118 00:07:38.875 --> 00:07:44.708 align:center line:-1 position:50% size:25% and the underlying security principles. 00:07:44.708 --> 00:07:49.167 align:center line:-1 position:50% size:37% ISO 15118 defines basically two types of authentication, 00:07:49.167 --> 00:07:52.042 align:center line:-1 position:50% size:30% one so-called external identification means 00:07:52.042 --> 00:07:58.542 align:center line:-1 position:50% size:47% which represents RFID card-based authentication in most cases. 00:07:58.542 --> 00:08:05.792 align:center line:-1 position:50% size:56% The authorization of a charging process is actually handled at the charging station, 00:08:05.792 --> 00:08:14.917 align:center line:-1 position:50% size:53% and there is manual interaction required between the EVSE and the user. 00:08:14.917 --> 00:08:21.958 align:center line:-1 position:50% size:47% The other type of authentication is so-called plug and charge (PnC). 00:08:21.958 --> 00:08:28.208 align:center line:-1 position:50% size:57% This is based on a public key infrastructure type of authentication. 00:08:28.208 --> 00:08:35.500 align:center line:-1 position:50% size:52% The overall idea is that any credentials for authenticating the charging process 00:08:35.500 --> 00:08:41.875 align:center line:-1 position:50% size:63% is deployed inside the vehicle, so the end user only needs to plug in the cable, 00:08:41.875 --> 00:08:47.083 align:center line:-1 position:50% size:62% and from that moment on, the EV is actually handling the authentication process 00:08:47.083 --> 00:08:52.750 align:center line:-1 position:50% size:63% towards the SECC (supply equipment communication controller) and the corresponding secondary actor behind. 00:08:56.125 --> 00:09:03.875 align:center line:-1 position:50% size:65% What is important to understand in this regard is the actual scope of DIN 70121 and ISO 15118. 00:09:03.875 --> 00:09:09.542 align:center line:-1 position:50% size:63% In principle, those standards define so-called primary actors and secondary actors. 00:09:09.542 --> 00:09:12.208 align:center line:-1 position:50% size:35% Primary actors are the EV and the charging station 00:09:12.208 --> 00:09:18.500 align:center line:-1 position:50% size:36% whereas secondary actors are any service providers 00:09:18.500 --> 00:09:25.250 align:center line:-1 position:50% size:56% beyond the actual EVSE, so these involve a certain type of back-end communication 00:09:25.250 --> 00:09:29.500 align:center line:-1 position:50% size:39% between the charging station and such service providers. 00:09:32.083 --> 00:09:40.667 align:center line:-1 position:50% size:56% In principle, the scope of these standards is limited to the front-end communications 00:09:40.667 --> 00:09:44.917 align:center line:-1 position:50% size:38% or the communication between the primary actors. 00:09:44.917 --> 00:09:51.125 align:center line:-1 position:50% size:47% All standards, as discussed before, the -1, -2, -3 and the DIN 70121 00:09:51.125 --> 00:09:55.458 align:center line:-1 position:50% size:64% really focus on the point-to-point communication between the EV and the EVSE 00:09:55.458 --> 00:09:58.083 align:center line:-1 position:50% size:36% or the corresponding communication controllers. 00:09:58.083 --> 00:10:03.333 align:center line:-1 position:50% size:43% However, due to this PKI-based authentication process, 00:10:03.333 --> 00:10:10.667 align:center line:-1 position:50% size:48% there are also a few items to consider for the end-to-end security, 00:10:10.667 --> 00:10:16.083 align:center line:-1 position:50% size:48% so particularly for the authentication of a charging process 00:10:16.083 --> 00:10:19.833 align:center line:-1 position:50% size:28% that are also defined in ISO 15118. 00:10:19.833 --> 00:10:27.833 align:center line:-1 position:50% size:51% All the certificate-related aspects that need to be covered by the EVCC, 00:10:27.833 --> 00:10:32.625 align:center line:-1 position:50% size:42% and the SECC implementations are defined in those standards. 00:10:32.625 --> 00:10:38.792 align:center line:-1 position:50% size:53% There's a limited dependency also here on the back-end communication 00:10:38.792 --> 00:10:44.542 align:center line:-1 position:50% size:55% which needs to be considered for the types of back-end communication, 00:10:44.542 --> 00:10:47.167 align:center line:-1 position:50% size:33% like, for example, OCPP (open charge point protocol). 00:10:49.625 --> 00:10:52.708 align:center line:-1 position:50% size:41% What is the underlying security architecture of ISO 15118? 00:10:52.708 --> 00:10:57.500 align:center line:-1 position:50% size:33% In principle, there's three security targets defined. 00:10:57.500 --> 00:11:00.042 align:center line:-1 position:50% size:22% On the one end, confidentiality. 00:11:00.042 --> 00:11:04.208 align:center line:-1 position:50% size:50% This is achieved through a transport layer security mechanism 00:11:04.208 --> 00:11:07.458 align:center line:-1 position:50% size:22% between the EV and the EVSE, 00:11:07.458 --> 00:11:16.333 align:center line:-1 position:50% size:62% so based on TLS 1.2 and -2 document, and integrity and non-repudiation are achieved 00:11:16.333 --> 00:11:20.167 align:center line:-1 position:50% size:49% through the application layer security based on XML security. 00:11:20.167 --> 00:11:24.792 align:center line:-1 position:50% size:50% These are the core functionalities and the core technologies being used 00:11:24.792 --> 00:11:29.208 align:center line:-1 position:50% size:40% in order to ensure that those security targets are achieved. 00:11:29.208 --> 00:11:33.000 align:center line:-1 position:50% size:62% The TLS connection that you can see here between the charge port and the grid operator 00:11:33.000 --> 00:11:36.458 align:center line:-1 position:50% size:55% is not part of the specification ISO 15118. 00:11:36.458 --> 00:11:42.875 align:center line:-1 position:50% size:66% That would have to be defined in a corresponding back-end communication protocol specification. 00:11:42.875 --> 00:11:50.958 align:center line:-1 position:50% size:70% For example, OCPP provides corresponding security mechanisms to employ such technology there. 00:11:54.500 --> 00:12:00.333 align:center line:-1 position:50% size:45% To enable these security features in 15118 for plug and charge, 00:12:00.333 --> 00:12:08.208 align:center line:-1 position:50% size:43% it defines requirements for a PKI and for multiple certificates, 00:12:08.208 --> 00:12:13.583 align:center line:-1 position:50% size:68% on the one end for the TLS communication session between the EV and EVSE 00:12:13.583 --> 00:12:22.250 align:center line:-1 position:50% size:59% and further certificate chains, also, for the XML security on the application layer. 00:12:22.250 --> 00:12:26.250 align:center line:-1 position:50% size:36% I will not go into the details on the PKI itself here, 00:12:26.250 --> 00:12:30.958 align:center line:-1 position:50% size:32% but what is important for the scope of testing, 00:12:30.958 --> 00:12:37.208 align:center line:-1 position:50% size:50% we need here, actually, various types of certificates and various instances 00:12:37.208 --> 00:12:41.833 align:center line:-1 position:50% size:49% in order to validate both a valid case but also invalid cases, 00:12:41.833 --> 00:12:47.625 align:center line:-1 position:50% size:48% so in cases where content of a particular certificate is non-valid 00:12:47.625 --> 00:12:57.042 align:center line:-1 position:50% size:64% and, also, the case where a certificate is either expired or is about to expire very soon. 00:12:57.042 --> 00:13:02.208 align:center line:-1 position:50% size:49% These are the few examples of what is needed in terms of testing 00:13:02.208 --> 00:13:05.500 align:center line:-1 position:50% size:44% to validate the corresponding plug-and-charge implementation 00:13:05.500 --> 00:13:14.208 align:center line:-1 position:50% size:57% and whether it is behaving correctly depending on provided input configuration. 00:13:17.792 --> 00:13:23.458 align:center line:-1 position:50% size:58% In order to give you an idea of what a plug-and-charge test execution looks like, 00:13:23.458 --> 00:13:29.542 align:center line:-1 position:50% size:43% we have prepared a short video to showcase the workflow. 00:13:29.542 --> 00:13:34.250 align:center line:-1 position:50% size:59% You can see here in the background our conformance test automation framework 00:13:34.250 --> 00:13:40.042 align:center line:-1 position:50% size:62% and with an overlay on top, we see the front-end of our system under test, 00:13:40.042 --> 00:13:45.667 align:center line:-1 position:50% size:51% in this case an SECC, so an EVSE communication controller 00:13:45.667 --> 00:13:50.542 align:center line:-1 position:50% size:45% and this is showing basically the state of the system under test 00:13:50.542 --> 00:13:53.750 align:center line:-1 position:50% size:34% that we are in during the test execution. 00:13:55.167 --> 00:13:57.125 align:center line:-1 position:50% size:27% Let's start the video. 00:13:58.875 --> 00:14:02.625 align:center line:-1 position:50% size:62% On the top left, you can see the test campaign with all the test cases. 00:14:02.625 --> 00:14:05.375 align:center line:-1 position:50% size:43% We are clicking on the test case in order to start a test run. 00:14:05.375 --> 00:14:08.292 align:center line:-1 position:50% size:44% On the bottom left, you can see the test parameters, 00:14:08.292 --> 00:14:12.583 align:center line:-1 position:50% size:46% a huge collection of test configuration parameters available 00:14:12.583 --> 00:14:14.833 align:center line:-1 position:50% size:36% for this particular test case. 00:14:14.833 --> 00:14:19.625 align:center line:-1 position:50% size:65% Now in the bottom right, you see a message sequence chart on the left-hand side, 00:14:19.625 --> 00:14:23.333 align:center line:-1 position:50% size:51% the main test components which is representing the test system, 00:14:23.333 --> 00:14:26.917 align:center line:-1 position:50% size:36% in the middle of the system under test interface. 00:14:26.917 --> 00:14:31.417 align:center line:-1 position:50% size:39% On the right-hand side, a PWM listening component. 00:14:31.417 --> 00:14:34.458 align:center line:-1 position:50% size:35% We have now run through the complete test case 00:14:34.458 --> 00:14:39.500 align:center line:-1 position:50% size:40% and are now basically waiting for the test case to finish. 00:14:41.583 --> 00:14:48.000 align:center line:-1 position:50% size:56% We then, in the next step, are going to the details of one of the other message 00:14:48.000 --> 00:14:51.458 align:center line:-1 position:50% size:37% that is relevant with respect to plug and charge. 00:14:51.458 --> 00:14:55.542 align:center line:-1 position:50% size:51% Though, first and foremost, we look into the SDP request response pattern 00:14:55.542 --> 00:15:01.708 align:center line:-1 position:50% size:62% to check if this was really a PnC session or TLS was chosen for transport layer security. 00:15:01.708 --> 00:15:11.125 align:center line:-1 position:50% size:65% Here you can see that the corresponding security property was sent by the SDP response. 00:15:13.375 --> 00:15:20.292 align:center line:-1 position:50% size:43% The next step is then to validate the payment details. 00:15:20.292 --> 00:15:22.917 align:center line:-1 position:50% size:38% Request a response pattern. 00:15:22.917 --> 00:15:24.958 align:center line:-1 position:50% size:51% We send the payment details request, 00:15:24.958 --> 00:15:35.375 align:center line:-1 position:50% size:56% we embody the complete certificate chain for the mobility operator, 00:15:35.375 --> 00:15:41.958 align:center line:-1 position:50% size:35% from the SubCA2, SubCA1 down to the root. 00:15:44.167 --> 00:15:52.583 align:center line:-1 position:50% size:59% In the last step, the authorization request, there we see the corresponding digest value 00:15:52.583 --> 00:15:57.750 align:center line:-1 position:50% size:51% that has been calculated and the corresponding GAN (generative adversarial network) challenge 00:15:57.750 --> 00:16:01.542 align:center line:-1 position:50% size:39% for the authorization request. 00:16:01.542 --> 00:16:12.917 align:center line:-1 position:50% size:67% You can see the complete X.509 certificate details are shown in the test system 00:16:12.917 --> 00:16:18.833 align:center line:-1 position:50% size:43% to allow a very detailed analysis of the test procedure. 00:16:21.000 --> 00:16:25.042 align:center line:-1 position:50% size:48% A lot more debugging information and debugging capabilities 00:16:25.042 --> 00:16:31.667 align:center line:-1 position:50% size:36% are available in the system to enable a deep analysis 00:16:31.667 --> 00:16:37.000 align:center line:-1 position:50% size:46% of all the plug-and-charge features during the test execution. 00:16:40.458 --> 00:16:45.250 align:center line:-1 position:50% size:47% Last, I would like to give you a short outlook on what will change 00:16:45.250 --> 00:16:49.167 align:center line:-1 position:50% size:26% in terms of security in ISO 15118-20. 00:16:49.167 --> 00:16:54.333 align:center line:-1 position:50% size:38% First, there's an update plan for transport layer security, 00:16:54.333 --> 00:16:59.292 align:center line:-1 position:50% size:31% so we will migrate from TLS Version 1.2 to 1.3. 00:16:59.292 --> 00:17:02.958 align:center line:-1 position:50% size:47% This will involve, also, an improved cipher suite selection, 00:17:02.958 --> 00:17:12.083 align:center line:-1 position:50% size:48% and the key length is increased from 256 to 512-bit key length keys. 00:17:12.083 --> 00:17:15.458 align:center line:-1 position:50% size:32% We will also start to use mutual authentication. 00:17:15.458 --> 00:17:21.542 align:center line:-1 position:50% size:49% Until today, so with the -2 document, we only had unilateral authentication 00:17:21.542 --> 00:17:29.417 align:center line:-1 position:50% size:43% where the EVSE provided certificate information to the EV. 00:17:29.417 --> 00:17:34.042 align:center line:-1 position:50% size:45% Now both sides will basically authenticate each other. 00:17:34.042 --> 00:17:40.375 align:center line:-1 position:50% size:44% For that, a new vehicle certificate is provided in the PKI. 00:17:40.375 --> 00:17:43.708 align:center line:-1 position:50% size:34% Another new feature is V2G session resumption. 00:17:43.708 --> 00:17:47.000 align:center line:-1 position:50% size:51% There is a binding between the V2G session and the TLS session 00:17:47.000 --> 00:17:53.875 align:center line:-1 position:50% size:41% which allows a quicker resume of a paused V2G session. 00:17:53.875 --> 00:17:58.292 align:center line:-1 position:50% size:43% In addition, there will be support for multiple contract certificates. 00:17:58.292 --> 00:18:03.458 align:center line:-1 position:50% size:44% In the -2 document, only one contract certificate was foreseen. 00:18:03.458 --> 00:18:08.708 align:center line:-1 position:50% size:46% There's optional support for TPMs, so Trusted Platform Modules, 00:18:08.708 --> 00:18:14.917 align:center line:-1 position:50% size:48% to provide a secure mechanism to save certificate-sensitive security 00:18:14.917 --> 00:18:18.958 align:center line:-1 position:50% size:26% and certificate data on an EV or EVSE. 00:18:18.958 --> 00:18:25.583 align:center line:-1 position:50% size:49% There is support for crypto-agility through secondary curves and keys. 00:18:27.958 --> 00:18:38.417 align:center line:-1 position:50% size:67% For Wi-Fi scenarios, so what we have seen before for the WPT (wireless-power transfer) or ACD (automatic call distribution) use cases 00:18:38.417 --> 00:18:44.958 align:center line:-1 position:50% size:43% there is also data link security defined as an optional measure. 00:18:44.958 --> 00:18:51.875 align:center line:-1 position:50% size:61% In addition, the introduction of a firewall concept to separate a trusted network 00:18:51.875 --> 00:18:58.667 align:center line:-1 position:50% size:70% where the SECC resides, from an untrusted network where the EVCC resides. 00:18:58.667 --> 00:19:02.250 align:center line:-1 position:50% size:52% With the completion of this lesson, you're done with Keysight's boot camp 00:19:02.250 --> 00:19:04.667 align:center line:-1 position:50% size:44% on EV and EVSE charging tests. 00:19:04.667 --> 00:19:06.292 align:center line:-1 position:50% size:22% Congratulations. 00:19:06.292 --> 00:19:10.167 align:center line:-1 position:50% size:63% We hope now you have a better understanding of testing combined charging systems 00:19:10.167 --> 00:19:12.583 align:center line:-1 position:50% size:46% and plug-and-charge applications. 00:19:12.583 --> 00:19:16.208 align:center line:-1 position:50% size:51% For more details, head over to the resources section of this course 00:19:16.208 --> 00:19:20.208 align:center line:-1 position:50% size:53% where you can download session briefs and white papers for further reference, 00:19:20.208 --> 00:19:22.375 align:center line:-1 position:50% size:34% or to get in touch with us. 00:19:22.375 --> 00:19:24.708 align:center line:-1 position:50% size:32% Thank you for attending this boot camp.