 My name is Piero Buratti, I'm working in Apigee for Automotive Product Group and I will give you some elements about the safety approach we are working on. So functional safety is part of an overall safety approach of the application you are developing and the objective of the functional safety, especially in automotive market is to avoid injury of people. The standard ISO 26262 is the standard that is regulating the approach the developer needs to follow to reach an acceptable level of safety. We have three main elements that are safety detractors, that are software fault errors and common errors. Software error is an error where a single bit value is wrong. Typically it is related to memory units and it is generated by radiation that are caused by package decay that produces some alpha that will eat the silicon and another possibility are cosmic rays that can eat the silicon. This can cause the change of the status of a single bit that can be a flip flop or a flash or run memory cell. We have a very big experience on this because we are part of a laboratory we have in the Alps between French and Italy and there is 1,700 meter rocks over and we are working there since here to examine the effect of these software errors. Latent faults, latent faults is a very difficult element to be discovered because are faults that nobody knows yet, never occurred. Maybe a new application can highlight a fault but at the moment the best we did we don't find this fault but we need to take care of them. Common errors, all the policies we will introduce to solve software errors and latent errors will introduce common errors because generally speaking we will see later we replicate, duplicate the elements to have a redundancy. Having a redundancy may be that we can have 2 elements making the same error so we have a false positive and this is a common error. In the past we were used to have a main MCU and a monitor MCU what we did is to have 2 microcontroller cores inside a unique device so we can make a monitor and activity on the same device. This requires a dual core lockstep mode approach. This device that we are introducing today is the Leopard and this Leopard has been certified by a third party that is Exida so we have introduced to them what is our architectural size. They have certified that are compliant to the standard. We implemented the device, they analyzed the implementation and say ok, I conform to the architecture already approved. So here is a block diagram, a simplifiable diagram of what a Leopard is. You can see highlighted the 2 cores, the 2 cross bars and so on that is our redundancy sphere. This helps to have the same operation done on 2 different modules and to compare. The element we have introduced here to avoid common error is this one. Each replicated channel is physically implemented in a different way. So, in reality the 2 cores are not so close, are as much as possible distant inside the device. The behavioral code is the same, but the synthesis mapping has been done using different rules and libraries so we have a different physical implementation. Then layout are worked to isolate the 2 cores inside the silicon avoiding to have a signal crossing them to exclude the possibility of crosstalk. Another important approach is the logical memory beast. Every time we switch on the device a self-test is performed on the full logical memory and the result is given. As much as we can run this test we are safer so we have decided to implement the logic beast not only on power on but also at power off. We have protected the flash and the RAM with the ACC traditional approach and we have replicated many control elements such as the temperature sensor, the voltage failure detection, the clock failure detection and we have taken all this stuff together to communicate with the FCCU that is default collection and control unit. This unit is programmable so you can instruct it to do already something for you so it depends on the voltage received can react autonomously for example can reset the device. In any case we communicate with outside to give information to the system of what default has been detected. Then we have a CRC unit. The CRC unit is used to have a signature on every serial communication channel we have. So all the peripherals that you can see in light yellow can lean flex ray and so on I have always a CRC signature so you can verify if the data transmitted is correct or not. So thanks to the experience we did in our lab we have developed a specific class of flip-flops that are insensitive to alpha and cosmic radiation and we have used this to harden the structure of our device. What we have today is the SPC-56 family, 32-bit microcontroller that is in full production and will stay there and all our devices are ASIL-B compliant that is a less important level and Leopard, the one I show you the diagram, is ASIL-D certified. In the future, 2016 over, all our devices will be ASIL-D certified. So we move from a pioneer to a strategic approach to grant ASIL-D for all our products. Unless you have a question, I'm finished and if you want to see some more detail about our products and tool chain we have a tripod just here on the left. Thank you.