UST034

34 with ISO 26262 and the EN standards that apply to railways, both of which are derived from standards created by the International Electrotechnical Commission (IEC 61508), van der Zwaan explains. “When it comes to individual vehicles for the road we have to look to ISO 26262, but from a transport system perspective we have the benefit of the railway standards,” he says. Those standards underpin the company’s engineering approach to ongoing development and any future software modifications, as well as their verification and validation (V&V) procedures, which are closely related but have different testing objectives. According to the International Software Testing Qualifications Board, a non-profit association, verification testing provides objective evidence that “specified requirements” have been fulfilled, while validation testing shows objectively that “the requirements for a specific intended use or application” have been met. In other words, the thrust of verification is to check that the development team has done what was asked of it in the documents that guided the development, while validation checks that the software can do what the user wants it to do. Both go through the same staged process, often visualised in the form of a letter ‘V’. The business case sits at the top of the downstroke flowing into the user requirement, system specification, system design and component design, while component construction is at the bottom of the V. The upstroke starts with component testing followed by interface tests, system tests, acceptance tests and finally release tests. “On the left side of the V, we also insert a number of gate reviews in our designs before moving into the implementation phase,” van der Zwaan says. “That phased and staged engineering is something we have invested in heavily over the past 10 years, and we now have templates in line with the ISO and EN standards. That means that when we have to undergo independent safety assessments we are well- prepared for them.” With electrical and mechanical engineering and vehicle assembly handled by partners, 2getthere concentrates on integrating the shuttle and configuring it as an autonomous vehicle. Its engineers are organised into separate teams that work on the embedded software and fleet management software respectively, while independent teams handle the V&V process. All software updates are integration tested before they are handed over to the V&V teams. “We typically build a safety case with an intermediate test-readiness safety case,” van der Zwaan notes. “Throughout the whole test cycle we have integration testing of software, testing against simulations with software in the loop and hardware in the loop, before moving towards vehicle-in-the- loop testing on a closed track,” he says. The first tests of the complete vehicle that the teams carry out on 2getthere’s own course prepare it for the Factory Acceptance Test (FAT) to prove that the safety functions are working properly. Only after getting over the FAT hurdle is the vehicle handed over to the customer for site acceptance testing. “This is all focused on functional safety and hazards related to that under the ISO 26262 standards,” van der Zwaan says. “Going into mixed operations, the SOTIF standards are increasingly important. That is about the behaviour of the vehicle October/November 2020 | Unmanned Systems Technology The shuttle’s front bumper, centre, showing the ultrasonic sensors in the black strip, the Lidar camera in the white strip and the radar