 Okay, I think we can start. We can continue. So we'll come after the lunch. I hope I will not talk you into the sleep. So if you feel sleepy, just raise your hand, and I will try to speak more silently and more slowly, not to distract you at all. And so in this lesson, we should finish the, let's say, safety characteristics of INC and electrical systems. So we will continue with the presentation. And I hope at the end, we will have, let's say, more time for discussions. And nevertheless, at the end of the day, there is, I think, half an hour for also discussions. So we can, if there will be more questions, so then we can also have discussion at the end of the day. So let's continue. So we have, before the lunch, we have spoken about most of the, let's say, basic safety, let's say, design requirements. So I would like to finish them. Then I think I would like to describe something with regard to testability and maintainability of the systems. I would like to, let's say, describe some specific with regards to digital systems, because they are nowadays used very often, mostly in INC, but in electrical systems as well, to give you some basic information about the development process itself. And at the end, we have enough time, so at least some little bit basic information about cybersecurity. Okay, so let's start. So fail-safe design. Again, this principle was already mentioned in previous presentations. So in fact, we want the equipment to fail in some, let's say, defined way. So we don't want some unpredictable behavior of the equipment. So for example, if we consider some loss of power or some, let's say, failure, which can happen, so we want the equipment to, let's say, put itself to some predefined or predetermined conditions or state. So for example, some output relays of some systems are put without, let's say, power supply, they are put to some predefined, let's say, position. So the methods, how to check and evaluate, there are more. For example, there are false tree analysis or failure mode effect analysis. We decompose the system and evaluate, okay, what would happen with the system if one particular, let's say, subsystem fails. What is, let's say, quite challenging the, let's say, safe state. Perhaps it's not safe. It's safe for one even, but maybe not very safe for another even, so consideration have to be put to this and there can be some discussion what exactly the safe state it is. But this is the, let's say, the basic approach what we have to do. What is the problem? Let's say the systematic errors in the design. Let's say specifically if we develop some software and if we introduce some error, there is some fault in the software. So the problem is that we can't predict what will happen with the equipment because if the software, if there is something fault, so it can do almost anything. So there is a very big effort to avoid such errors. And again, let's say how to deal it is, in fact, application of diversity and so on, but very high quality development process is one of the, let's say, most important, let's say, remedy for these types of errors or problems. And we will speak about it in more detail a little bit later. So here are some, let's say, just examples how we can implement some fail-save design features in our equipment. Of course, it's very specific for different type of equipment. We can find different solutions. So this is just an example for you. So independence, we spoke a lot about independence. Data validation, so basically the receiving system check the data which it receives. For example, if it's out of French or some, let's say, nonsense value. And so the aim is to, let's say, not to propagate the failures. Data buffering, so it's something which is, let's say, simplified, disimplified scheme. So basically if we have some communication link and some receiving station, so usually what is done, so the communication link put the data to some shared register with its own, let's say, time cycle without any interference with the, let's say, receiving station itself. And then receiving station with its own, let's say, time cycle when it needs, it reads the data from the register and, for example, writes down the output data. So the independence is there because if, for example, this link turns crazy and starts, for example, generate some station, try to overwhelm the link. So the station has its own cycle and perhaps it will find that, for example, these data are not refreshed or are some, let's say, not valid, but it will continue the operation and can have some, let's say, outputs, for example, for some hard-write outputs to the technology and it's not, let's say, influenced by the fault of this communication link. So this is another example how to deal with, let's say, independence and fail-safe design. Yeah, then, for example, the relays are energized, so they should switch to some predefined condition, use one-directional communication links and things like that. Of course, if we implement some, let's say, for example, data validation algorithms, so we have to also consider that such algorithms could fail, so we have to implement such algorithms in the same rules because it's part of the safety system, so same, let's say, methods and rules apply also for this, let's say, additional functions. And always we try to keep it, let's say, simple, not to implement something very complex. Also, the same implies for electrical systems, so we should be able to, let's say, detect faults in the electrical system of the plant and to switch off some of the parts of the, let's say, scheme or the busses, which are, let's say, faulty or, again, everything is aimed to, let's say, prevent propagation of failures. So we can use some safety relays, some circuit breakers to, let's say, isolate the faulty part of the electric system. Okay, this is about margins. We heard and discussed this topic, I think, in the first day. So, in fact, the margins and conservatism, it applies also for INC systems. So, just to remind, so there is some safety limit, which is basically some, let's say, physical limit of the equipment, which we really don't want to reach. So then we have some analytical limit, so this is something which is used in analysis. So, there are some margin, which takes into the account some uncertainties. And here's the normal operation. So, in the normal operation, this is where the control system, let's say, tries to keep the process. But if something goes wrong and the process, let's say, turns from the normal conditions to some abnormal or, let's say, accidental conditions, so we have to have some limit from where the, let's say, safety system starts, its operations start to provide the safety functions. And this, let's say, set point or threshold is, again, let's say, set with a guard or it takes into account some, let's say, margin, some conservatism. And the margin has to take into account, let's say, that the instrumentation is not perfect. There are some, let's say, measurement errors. There are, for example, some response times that when the technology reach this trip or this threshold, so it can take time for the INC systems to evaluate, to, let's say, provide the action and perhaps then it takes some time. The technology itself, I have some, let's say, it takes time to cope with the, let's say, safety action. It could take time to see the results of this. So, again, margins and conservatism is applied in the INC systems as well as you heard about it before. And so, if this is, let's say, threshold for the safety system and this is, let's say, some normal operation where the control systems work, so the, let's say, limitation system will be somewhere in between. So, again, the defense in depth. So far as we have the control systems, if something goes wrong, so then somewhere here should be, let's say, some limitation system which try to, let's say, put it backwards to the normal operation, but if it's breached as well, so then we have the safety systems to cope with this situation. So, margins are implemented here as well. So, this one, yeah? Okay, so basically, so to start with, we have the safety analysis. The safety analysis is, let's say, the major source of the information for this because during the safety analysis we evaluate different scenarios. So, for example, if there is a steamline break, so it will develop and in a certain time, in certain, and there will be some, for example, some, let's say, range in which the, let's say, safety action has to be provided not to reach this limit. This is the maximum limit and in the safety analysis it's calculated in a different, let's say, time sequence, in specific time sequence, okay, there is an event in, when the, let's say, technological parameters reach some, let's say, threshold, then it operates and then there's some time sequence where, let's say, the process should, let's say, return all stabilized but basically we don't want to, let's say, breach this analytical limit and the proof is basically the safety analysis and the bases are, let's say, the errors in the measurements, time response of the INC equipment and also the behavior of the technology itself because for some safety action the result is very quick but for some, for example, some heat removal it can take time, yeah, so we have to, let's say, operate it to have enough time to, let's say, stabilize the process and not to reach this limit. Is it okay like this? Okay. It's, yeah, it's not easy, yeah? There is no easy way how, and there is no, let's say, prescribed values. You have to be calculated for the, for the specific design to see what the values have to be. So basically, based on safety analysis, you have this limit or analytical limit, usually this is set by operator regulator, you have some limits which you cannot breach because then there will be the possibility that you can lose, for example, the integrity of the system or you lose the, let's say, fundamental safety functions but again in the design and it depends on the, let's say, how it's organized by the operator but usually as far as I know the safety analysis are usually done by, let's say, operator or by some higher threat party so it depends if the operator, the plant has the capability to, let's say, calculate or evaluate the safety analysis. So very often you, let's say, pay for some, let's say, other company which has the capability and the tools to do that but it can be done this, there are two ways, these three set points, it can be defined by the designer. If you, let's say, buy the safety system from him and you give him these limits so the designer can calculate the safety analysis provided to you and show you that, okay, I set the set points like this and this is the proof, I calculate the analysis so you have, let's say, you will not breach this limit so it can be done like this but at the end, you as an operator have to check to see if it was done properly, if they include everything they should include and also then the regulator is the one who would like to see this, to see the analysis and the results, to see to evaluate, okay, and ask the question if, okay, do you consider this and that? So more ways are possible, you can buy this service but nevertheless, you as an operator are responsible, you are responsible, your ultimate responsibility for the safe plant is up to you so you have to check and not to believe everything what the supplier tells you but to check that, okay, it's some reasonable and ask questions. Usually what the regulator, let's say, approved is usually this one, yeah, and you have to show the regulator that you set, for example, some specific value that you are, let's say, below this limit so this is what the regulator is interesting for. So the regulator usually is interested to know that in never, let's say, combination of condition you will breach this limit and for them it's perhaps not very important what the specific value is but the result is that it can't be breached so this is what, let's say, is essential for the regulator but for the plant operator you have to, let's say, deal with specific value in the system, yeah. Again, it could be very different. Usually the evaluation that the system can work, for example, the digital system, which is quite simple, it works, for example, it's like milliseconds so, for example, one cycle can be 100 or 50 milliseconds then you have some, let's say, delay introduced by the sensor itself. The sensor, it depends on the, let's say, physical, let's say, approach how physically the sensor works so it can be, let's say, milliseconds to seconds because, for example, if you measure some, let's say, lower Newton power, so it can take more time to, let's say, count, for example, the policies to evaluate what the level of Newton power is, for example so it could be different from milliseconds to seconds and also you have to consider if there are some communication links so there are some cycles for the information to travel from the sensor to the, let's say, system, INC system itself and then from the INC systems to the actuator so you have to, let's say, evaluate all the chain. You usually do that for some, let's say, typical, you can, let's say, build some typical chain for analysis so because usually the INC equipment runs in some predeterminized or predefined loop you have some different types of sensors which behave, let's say, in the same way so you can have some, let's say, five, four, six typical chains which will evaluate for the, let's say, response time but it's not easy, it requires the knowledge if you have to know every, let's say, part of the chain to be able to find out or to estimate what the time will be. Some example of these values. Okay, I will have to find out maybe from my plan some example. Okay, I don't remember the specific number so perhaps because it's very, very different for each plant and each design so for example, it could be, for example, temperature in the primary circuit so perhaps I don't remember exactly the analytical limit could be something like 310 degrees and the trip set point will be something like 3105 degrees so it can be something like that so the margin here, it depends on the, let's say, the technological process for which it applies but it's, let's say, between one and 10% so something like that, usually. Okay, so qualification, we have spoken about it earlier so let's skip the qualification. Testability and maintainability. So in fact, the systems which are important to safety should be designed that we can, let's say, test them and let's say, maintain them. So why, let's say, why we need to test the systems because we have to be sure that the system is still in good condition and it's functioning and of course the maintenance activities so there can be some activities which are, let's say, as a result from the qualification but also there can be some, let's say, corrective maintenance because something can fail so we have to be able to, let's say, put the system back to the, let's say, operational status so in the design we have to consider that the system has to be tested somehow and we have to be able to repair this. There can be some, let's say, specific tasks like a sensor calibration and things like that so just we have to keep in mind that such activities are also important during the lifetime of the equipment. So, let's say, provision of the testing, the scope of frequency of the tests are usually based on some, let's say, reliability calculation and based on some, for example, mean time between failures and also the systems very often have some, let's say, self-testing capabilities so let's say quite usually a large portion of the system can be tested online automatically but there are usually some portions which are not covered by self-test so then we have to periodically test to see if there are no error, no faults in this, let's say, part which is not covered by the self-test. What is also important, we have to be careful that if we implement some, let's say, testing tool that we do not, let's say, compromise the independence or introduce some common cause failure because in some design, for example, you can have some specific testing equipment which is connected to all of, for example, three or four divisions and just is, let's say, activated for one division then for another division and so on so you have to be very careful to evaluate that such, let's say, common equipment cannot, let's say, cause the common cause failure of all the safety divisions. So, this is some, let's say, consideration that, okay, there can be some, let's say, exceptions because sometimes it's not possible to test everything whenever we need so there are some, let's say, specific parts of equipment which are, which it's possible to test only, for example, during the OTGs so then we have to, let's say, consider that if there are some equipment which are, for example, not accessible during the operation so they have to be, let's say, reliable enough for example testing them once a year is sufficient so it's possible but just to know that if something fails very often so most probably we'll need to test it more often and if there is something which is not easily accessible so we have to put something more reliable there and what usually is done is, let's say, overlapping tests so basically it's usually it's not possible to test all the chain, everything together so usually it's some combination of some self-tests of some, let's say, tests of some specific parts which, let's say, overlap a little bit and then we are able to evaluate from, for example, three or four overlapping tests that the all, let's say, safety group or the all the chain is, let's say, in good shape. What is also important, if we test safety system or the safety group or safety division or safety chain or whatever we call it so one thing we have to be able to, let's say, properly identify the system it seems quite obvious but there were, let's say, very, let's say, severe and there were also deaths caused by the maintenance personnel didn't recognize the, let's say, equipment which was, let's say, dedicated or where they're supposed to work and they go to another place and they were killed, for example, by the electric current so there should be, let's say, some methods and clear identification of what the equipment, what is it, so to be able to identify all the equipment at the plant clearly. And also we have to be careful that if we put some part of the safety system offline or bypass it for the testing so it should be indicated, we have to know that some portion of the system is offline for the tests and we don't want to stay in the tests like unwanted even, so after the test we have to be able to switch it back on and the operator should have some, let's say, information that, okay, the system is now running in full configuration so also some, let's say, information should be provided and the consideration should be provided to the fact that we have to be able to identify that the system is under testing and that the system is offline for some reason. Spare parts, yeah, we have discussed these topics so I think we will not spend a lot of time on this so we spoke mainly about the qualification so there are also another, let's say, aspects of the spare parts, so the availability of the spare parts the storage conditions, yeah, some spare parts are, let's say, sensitive so we have to put them into some specific conditions or test them also because after, for example, 15 years in the warehouse maybe they will not work and configuration management is more about quality but we have to be able to identify what happened to our equipment if there are some spare parts were used or some portion of the equipment were repaired so we have to be able to trace the history of the changes of the equipment to be able to prove that, okay, the equipment is all the time good enough it's still qualified to provide the function when needed under the conditions, expected conditions so spare parts, supporting systems so from the point of view of, let's say, electrical and INC systems so, let's say, quite usual supporting system is the air conditioning there are many systems which require, let's say, cooling or air conditioning to keep it in the, let's say, qualified state in the mild condition or mild environment when such, let's say, support or auxiliary system is necessary for the, let's say, correct performance of the system so it has to have the same, let's say, qualification the same requirements apply also for this system so, for example, when I need air conditioning to my safety divisions so then I have to have, if I have four safety divisions so I have to have four independent air conditioning for each of the division so same requirements apply if it is, let's say, necessary for the, let's say, proper safety function of the equipment management process so several times we have mentioned that, let's say, quality assurance is everywhere so I think it's not necessary to spend much words on this but also the high-quality development process so, again, the high-quality development process especially for the complex system is very important and is, let's say, one of the basic requirements that we have to implement such, let's say, process that we are sure that all the safety requirements are correctly implemented in all phases of the design and there are cases that at the end when the equipment is ready and manufactured so perhaps not everything is possible to test so that's why we have to, let's say, be interested how the design process was created out and perhaps to check the manufacturer how he, let's say, provide, how he, let's say, do the activities again, it's about design process itself so I think we have mentioned it already so let's skip this to have maybe time for some discussion so now we are, let's say, more about some more specific about digital systems because nowadays in nuclear power plants in older ones there are some, let's say, modernization activities in new builds most probably you will, let's say, find digital systems also as safety systems as well not only in the field of INC but also you will find digital systems in electrical, let's say, systems because digital there are starting with some smart devices and continues to some, let's say, a very complex PC-based system so again we have specific requirements that we have to be very careful about all, let's say, a life cycle of such, let's say, complex or digital or computer-based system so some, let's say, basic characteristics of the digital systems so in fact why we use it because as you have listened or heard that we have some concerns about common cause failure about the high quality development process so perhaps it would be better to avoid them completely so maybe yes but they have some advantages so first you can implement very complex functions so which usually can be, let's say, very user-friendly HMI there can be some specific, let's say, analytical functions and you can implement almost everything you need so this is, let's say, pros but on the other hand it can be quite complex, difficult to test and there can be some hidden faults if it's too complex it's quite flexible so you can easily, let's say, change if it's not, let's say, if you find out that something, for example, some set point can be changed or some algorithm so it's not so difficult but again there are some concerns about, let's say, configuration management we have to, let's say, trace all the changes and about also cybersecurity because we don't want that someone changed something which we don't like to be changed it's easy to reuse so it can be very effective when I can develop the software for, let's say, one safety division and then, let's say, very easily migrate it to other divisions so the development process can be very effective and maybe a little bit cheaper than when I need to develop every, let's say, safety division separately but again, common cost failure I can, let's say, buy this copy and paste I can introduce the same faults in other divisions so improve diagnostic self-test this is very, very good, we like that again, too much complex digital systems, yeah, it's discrete systems so there can be some, let's say, sampling problems or some unpredictable transients between, for example, different digital systems communication links they are quite small very small form factor in small chip we can implement a lot of functions but there are some specific conditions so for the, remember that the silicon chip don't like high temperatures, don't like radiation so we have to consider this and, okay, complex functions okay, I think it's okay so this picture is just to, let's say, demonstrate where we can find the digital system how, let's say, complex they can be it's usually not obvious very quickly that, for example, we can have some smart devices which can have firmware firmware can be, let's say, pre-developed or specifically configured for our, let's say, application then we have some, let's say, INC or electrical system with some, let's say, specific customized application functions usually with some, let's say, system or operating software there can be different libraries, specific configuration we can have, let's say, standard PC-based for example, some PC-based diagnostic system is, for example, Windows operating system specific application which is configured and apart from that, during the process we need a variety of the digital and test design and testing tools we have source code, we have tools for maintenance and diagnostic, we have a lot of documentation we have spare parts because we have the spare parts so we have to, let's say, take care that we have the same, for example, firmware version which is compatible with the rest of the equipment which can be also a problem to, let's say, trace all these, let's say, links in between software backups so the digital systems can be really complex they have advantages but we have to, let's say, consider all these elements have to be, let's say, consistent to each other and let's say, qualified the systems have to be qualified properly as we have mentioned morning and the high quality development process is one, let's say, one of the key key element of this, let's say, qualification and we will speak about it also so I just would like to draw your attention but we don't have only, let's say, software-based we have also FPGA I think you already heard, you perhaps know what FPGA is it's also, let's say, digital technology but it's used a little bit different, let's say, approach so while the software-based is the silicon chip basically transistors together with some operating or system software which provide the interface between the chip and the application software so FPGA is also integrated circuit but in this circuit there are, it's the field of programmable gate arrays it's usually, it's AND, XOR, and flip-flop arrays which are, let's say, connected together and during the, let's say, programming we just, let's say, connect different gates together so the result is, in fact, the hardware it's specific chip where our brand connections between the gates without, in fact, any software so this is specific, it has some advantages but also some, let's say, some consideration has to be taken into account so the development process, it's almost the same also in both these digital systems you need really, let's say, well-established and well-controlled design process you also use very complex tools so for both of them in both of them you can have some, let's say, pre-developed items, some tools, libraries something which you have to, let's say, perhaps problems during the qualification what is good for this FPGA? The complexity is much lower, really so this is a good thing the bad thing that if we really want to implement something really complex, typically HMI so the software-based systems can be better for this processing, sequential parallel, design so there are some similarities but these type of digital systems are nowadays, let's say, used more often in the plan design and the plan systems as well so now at least few words about the design process we have mentioned it several times that it's important so a few words I don't know if someone of you is programming as a job or as a hobby I don't know if you program at something maybe at university so when I usually program something at home so I usually do like this I just throw the code and try and find out that it doesn't work and so on so this is used very often in that's a normal life but this is not good enough for the let's say nuclear application so for nuclear or safety systems or safety related systems the design process how it's, let's say, recommended is like this, this let's say V-shaped development or design process this was taken directly from the INC safety guide the, let's say, characteristic of this it's sequential it's very, let's say, well defined you have specific steps and you have defined interfaces between all the steps so it's very well controlled, well described the problem is it's quite inflexible it's quite rigid and here if you find out that you have to change something here so it's quite difficult you have to go back and go through all these steps again so, but basically this approach is, let's say, incorporated in all the, let's say, standards for the, let's say, safety systems development which I saw here so in IEC standard, IEEE standards, IEA so this is considered to be good practice how to develop the, let's say the software or let's say also the hardware perhaps it's not the only its recommendation but this is something which, what is used I will not describe all the steps there are a lot of literature on this so you can study, you can find on the internet many information so let's continue I would just like to mention some, let's say, specific specific issues with regard to this design process so first of all everything start with very good planning so everything has to be planned and described so the process, the interfaces have to be very well described before we start and this is something which usually, let's say, the operator and also the regulator would like to see to have some proof that the process will be, let's say, well controlled that the, let's say, design codes will be, let's say, implemented properly one of the most important, let's say, steps if, let's say, specification requirement specification, it's right on the beginning when we, let's say, prepare the specification requirements how the system should, let's say, be built what the system should do what the requirements are this is according to the operational experience this is the major source of the failures and the problem is that either the requirement is not, let's say, clearly adequately stated or maybe it's not understand by the designer so this is typically, this is the communication error so when I need something I will try to describe but someone else read it and understand it a little bit different so very often these requirements are not complete they are perhaps not correct and they are not clear and so this is the result of and if we find it at the end of the development process so we have to go back and it could be very, let's say demanding to correct and so very, let's say attention has to be paid to the initial steps of the design because the design process itself then use this throughout all the design steps and if there are mistakes it's made in the beginning so then it goes through all the design to the end and also that's why, for example the functional diversity is quite effective because if you, let's say, describe requirements for two different functions so usually there is lower probability that on both description, on both requirements there will be some misunderstanding but on the other hand if you have the same function which is described somehow and the same function is implemented in two different designs so even if you have, let's say, design diversity but if you implement incorrect or wrong requirements so then you can have common cause fail implemented in the, let's say different systems as well, yeah, so specification faults you have to be very careful about this and put attention to the beginning of the process so there are some we have already mentioned so complexity should be the systems should be simple, predictable and so on so let's skip this verification and validation verification and validation I think we had some discussions verification is, let's say, an ongoing process so during the old design process we have to check to verify that the output of one activity is, let's say, good enough to continue with another activity we have to verify or check, let's say, different documents which are produced and at the end there is a validation something like, let's say, the final evaluation of the requirements and the approval of the, let's say, product that, okay, it complies with the requirement and it's good enough to, let's say, integrate with the plant and so on so this is the difference between verification and validation here are some, let's say, approaches this is based on, let's say, experience what is done, it's not, let's say, prescribed anywhere, anywhere what is prescribed or what is acquired so the, let's say, verification and validation team, VNV team, there should be some, let's say, independence, there should be independence in, let's say, management there should be independence in money so it should be independent enough to get us, really, let's say let's say, valid results so what are the approaches as I saw during different projects so the most, let's say, independent approach is that, okay, you use for the VNV activities completely threat party, another company so this is the, let's say, most independent solution the drawback is that it can be quite, let's say, time demanding, maybe quite, let's say, also expensive because usually the threat party don't have perhaps the specific knowledge of the system itself so there have to be a lot of communication but it's, let's say, completely independent another approach is to have, let's say, independent VNV team inside supplier organization so it could be, let's say, more, let's say, maybe time effective because this VNV team inside supplier perhaps know the processes, know the system itself so perhaps it could work, let's say, more, let's say, effectively on the other hand you can see that the independence is not so strong here so if such approach is, let's say, adopted we have to be very careful to evaluate that the VNV team has sufficiently independent management, independent people and some, let's say, specified budget to do the activities because we don't want the supplier, let's say, cut the budget for the team and tell them, okay, don't check it it's okay, we have to be sure so then for utility and perhaps regulator there's more effort to evaluate that there is enough independence but it can be done and, let's say, least independent is, let's say, independence just in the design team such approach is usually used only for, let's say, some safety related I never saw such approach for safety systems and basically one guy do the software and another guy check it and vice versa so only for some, let's say, safety related systems such approach can be used under certain conditions so this is some, let's say, possible approaches to VNV activities system validation, I have mentioned at the end to validate that all requirements are met okay, everything has to be documented and recorded, again, quality assurance a lot of documentation then when the system is installed at the plant, so you have to consider that usually there have to be some specific testing because not everything is possible to test let's say at manufacturers or at factory so you have to test the interfaces maybe you need to test some, let's say, maintenance procedures because from designer you perhaps receive some, let's say recommendation how to maintain the system so we will need to check that, okay, it works like it is described and basically I have already mentioned all of these from all the design process there is a lot of documentation and the documentation is not only for, let's say, licensing but also we need, let's say, detailed documentation then during the operation when we try to find some behavior of the system so we have to be able to have some source of information to find out how the system works how it is built, how it is interconnected and when we, let's say, would like to make some design change later so we need to have enough documentation to be able to let's say approve to provide, to plan to, let's say, think about how to change it in a safe way very, let's say, big topic is traceability this is a very, very big topic and quite challenging I think in every project I saw there were some problems with this because traceability it means that you have to be able to trace all the requirements just from the beginning as you specify them through the design to the very end of the, let's say of the design process to the validation so at the end you have to be able to validate that all the requirements which you stated at the beginning where, let's say, incorporate it into the design and test it in the end so it's in fact the clear link between the requirements, between the design between the testing and you can imagine that there is a lot of requirements there are many sources of requirements from the licensing point of view, different standards so it's not very easy there are some, let's say, there are tools which can support these activities but it's, let's say, more about quality assurance this one but it's required to have such traceability and it's really very challenging issue human factor engineering we haven't mentioned it there will be, I think, there is some, let's say specific presentation on that topic I would like to, let's say, just mention that human factor engineering is, let's say INC and electrical systems very often are usually have some interfaces with the people so we always have to consider these factors very often, at least according to my experience in some, let's say, design changes is underestimated but it's integral part of the design process during the requirements, during the evaluation of the design we always have to think of the interface with the people so we have to evaluate, okay how the people will interact with our systems we have to classify the, let's say human-machine interface items so we have to know which one are, let's say, important to safety which perhaps not and also we have to find out if the operator is required to provide some manual action so we have to be able to prove that he has, let's say, enough information to decide that the action is needed and he has, let's say, the means how to operate the equipment so these are, let's say, basic considerations which we have to, let's say, consider during the design so it's not only about, let's say, the functions itself but it's also about the human factors okay, so let's speak at least a little bit about cybersecurity as well just some very basic information nowadays it's quite a hot topic because the systems which are using the, let's say, standard IT or computer-based technology are nowadays used very often in the plants as well these systems are usually interconnected to each other and so the cybersecurity starts to be, let's say, the issue as well so in the SSR slash 2 you don't find anything special about cybersecurity you just find that you have to prevent unanthorized access this was usually, let's say, taken from the point of your physical access to the equipment that okay, you have some fence, you have some guards you have some locks so no one which is not authorized can cannot, let's say, do something with the equipment but now with, let's say, digital world you can have also digital access if the systems are connected to the, for example, plant information system and the plant information system is connected to the corporate network corporate network is connected to the internet so there can be, find some, let's say, links from the outside world to the inside the plant so now this requirement has also some, let's say, a little bit other meaning IEA is working in IEA there is NSS 17 so this is one specific document concerning cybersecurity and I think that in preparation there are, I think, several documents or four specific documents with regard to cybersecurity I'm not sure they were not issued yet, I think but the IEA is also, let's say, paid quite attention to this topic so basically when we use digital systems at the plant so we have to deal with the consequences of cyber compromise so this is the basic message so here are some, let's say, specifics we have, let's say, cybersecurity problems because we use standard IT technology it's because perhaps other is not available it's cheap, it's usually well proven so also nowadays in, for example, PLCs you can find some Unix or some Linux operating system so the standard IT technology is more and more used in the systems and not only INC but also in electrical systems as well but INC is, let's say, the most the major user of this technology but on the other hand IT technology has some, let's say, characteristic but INC system was a little bit different purpose a different characteristic which can lead to some problems so, for example, we usually work in real time with limited resources so it means that it's a problem for us to implement some specific cybersecurity let's say measure some antivirus or things like that because it can increase the complexness of the system maybe we have not enough resources for that we need the systems in, let's say, high availability so we don't want to, let's say, switch it on and off very often, usually with IT it's not a concern other things, for example what is quite important usually the INC systems we operate for a long time 10, 20 years, it's possible with some PLCs so it's clear that from the IT point of view these systems are obsolete without any support and very often there are some, let's say, proprietary systems so we have, let's say, quite limited access to some, let's say, more resources and so on so IT systems are used in the INC but INC has specific characteristics which somehow limit us how to use some cybersecurity measures and we have to, let's say, take care the most important is that usually in IT the confidentiality of the data is usually the most important things because there are some security data, some financial data, personal data and things like that but for INC system usually there's not very secret but the problem is integrity and availability we need to have correct data in the right time so these are the big differences so how to deal with it? so basically, again, some, let's say, defense and death principle applies also in this approach so again, graded approach is used also in the cybersecurity we will not speak about details because it's a very specific topic but here's some example how it could be implemented just to give you really some, let's say, very rough let's say, example how it could work so under, let's say, most protected level there's the protection system then we have some, for example, some process control system we implement just one way communication link because we don't want to, let's say, harm or loss lose the protection system from the outside then we can have some, for example, process information system very often this also one way then we have some, let's say, support system it's for work permits and so on so these are, let's say, it has influence on the operation but maybe there's no influence on safety and we have some, for example, office systems, emails financial systems things like that so this is one possibility how it was, for example, suggested by an RC guide you can download this regulatory guide about cybersecurity, you can read more about it it's quite detailed you can also download the IEA NSS-17 document you have more information on that so before we finish and have some, let's say, enough time for some discussions because we don't have enough time before lunch so just I would like to maybe emphasize some myths about the cybersecurity these were publicized, I don't know, 2009 still when I speak with some people they still are very persistent in this so I just would like to, let's say, to share the very often, let's say, misunderstanding so the first thing is that, okay when you speak with the people so very common answer is my system is isolated so I don't need to take care about cybersecurity, it's somewhere in the plant locked in the cabinet and so why the problem is that very often you will find some communication links in between some upper layer systems if not the links so you have some maintenance work which use some diagnostic tool for example some, let's say, laptop or diagnostic notebook which is used, let's say, to connect to the system for some diagnostic and so on and which can introduce the, let's say, and bring some, let's say, malicious, let's say, code from outside so nothing is, let's say, really isolated this is the first thing I have just only one way communication links so this is a good thing, we really want to implement them but it is not so easy to prove that the link is just only one way it's not so easy there are some specific devices devices called data diodes which, let's say, in a hardware way can, let's say, provide one way communication but very often even if the communication is, let's say, standard communication and from the logical point of view the one system send the data to another system so very often we'll find some, let's say, on the system level some handshake, some, let's say, communication some questions on the system level between the systems so very often the one way is not as one way as it should be I have firewall or antivirus so I'm secure so it's good to have firewall or antivirus this is a good thing but in this field there is no simple solution always there could be... it's, let's say, an ending battle between the black guys and the white guys and always the antivirus or firewall is not 100% secure so always we have to implement some more let's say levels in depth more barriers because no antivirus is able to find 100% of all malicious code you have something called zero-day the vulnerabilities so it's the vulnerabilities which are, let's say, not yet publicly known so perhaps the antivirus don't know that such code exists so this is also not true and also what was, let's say, very often in the INC and specifically in the nuclear security by obscurity so it was, okay, my system is so specific developed by company X company or by Y company or whatever so it's very specific, no one knows how it really works so no one can say harm me so still this could be true for a very specific system but as I mentioned very often nowadays also the INC, PLC, and so on use let's say standard technology standard communication links which are well defined you can find the definition of the communication protocols on the internet and also the industrial devices was and could be, let's say, target of attack so be careful if you will speak with someone so most probably you will hear some of these so be very, very cautious about these myths okay, maybe one of the last things there is a very specific requirement that we have to be very careful so when we implement, let's say some security measures we don't want to harm the safety because it would be very easy and here you can feel you can see that there are some contradicting requirements, on one hand we want to have the system secure as much as possible but on the other hand it has to be simple we have to be able to test it and we don't want to block the system for example for the operator we don't want the situation when the operator needs to, let's say, information and then the system tells him log out and the wrong password you have to contact the hotline to get new password and something like this so the security measures should not and shall not compromise the safety measures and vice versa so this is quite, let's say, challenging because we have contradicting requirements and we have to deal with it somehow okay, so just at the end of the presentation I put some, let's say content of design basis for INC and electrical systems is just for your reference to see what type of information you should find in the design basis I will not go through it I think it's no sense, we have already mentioned all of these, let's say, specific things so I think this is all about, let's say if you would like to use it so you can read it at the presentation so it's just as a reference for you everything, and at the end you have references so mostly I use this one but you have more of these so you can find out most of them you can find out for free at the internet and use for your, let's say, use okay, so let's stop here to have some time for some, let's say discussions or questions it was a lot of information so I think you are exhausted after this but if there are any questions, so please so maybe some some of you have some, let's say experience which can be shared with the others so some remark so please, if any questions or remarks okay yeah, exactly, very good, yeah yeah, perfect, yeah this is very good remark thank you for that it's very important and in fact according to the, let's say, experience the most, let's say, harm was done by insiders, yeah because the insiders have the information usually they have the access maybe some of the harm was not maybe intended it can be also unintended but yeah, usually the maintenance staff they can unintentionally, let's say put some code, some USB flash disk to with some codes of perhaps it's not intention but yeah, this is very, very, very important to be, we have to be careful about internal people, we have to train them so the awareness of the cybersecurity is very important it's very difficult because usually people fight it because cybersecurity, let's say, quite restrictive it's put some restriction on how the people are used to work so they usually don't like it because they are forced to, for example, check the system or perhaps they cannot do it the way they were used before so it's important to explain why it is and yeah, for insiders according to my experience we also have some issues always from insiders, yeah very good, thank you very much for this any remark or question or some notion or some experience to be shared with the audience okay, so maybe we can also if something came up so we can discuss at the end of the day so I think now we can have a break and we will continue at 16, so 4 p.m. okay, so thank you for your attention