So, the next topic is the analysis or assessment of safety over the lifetime. This is an interesting topic because this can create most of the headaches for the operators because they have to spend money on safety assessment once the plant has already been licensed and they start the operation according to the license and everything and then comes the regulatory body saying that, hey guys, do you follow your safety assessment and do you update your safety assessment with the changes and everything? So it is then the plant has to organize some projects which fulfills the tasks of the requirement in relation with the requirement. So, unfortunately, at the beginning of our nuclear power plant operation back in 1980, 81, 82 and so on, such requirement didn't exist and then the first so-called periodic safety review should have been submitted to the regulatory body 10 or 12 years after the start-up of the plant and at that time we in the country did not have regulatory guidance on the content and how to perform such periodic safety review, so-called periodic safety review because at that time already it was called so and therefore the plant management or the plant technical stuff, technical management and the regulatory technical management sit together to agree on some kind of content. After that, of course, it was after the first year period which included also so-called re-evaluation of the safety, which I have already talked about, that was a complete re-evaluation of all safety, producing all the safety analysis including the probabilistic safety analysis and the deterministic safety analysis together with the severe accident analysis. And once it was done, after that, after 12 years of operation, we can say that the flow of the normal life went into the right track. So after that, the periodic safety review was required with the periodicity, predefined periodicity, so not on a not whole basis. So the assessment of the safety over the lifetime of the plant and the periodic safety reviews, this is the presentation title. Now I will have some introduction design lifetime considerations because this is also a topic here. Then the modifications and design changes, how to take them into account and what to do with them. And finally, the periodic safety review reports in relation with the periodic safety reviews. So well, we know that the nuclear power plant safety is changing by the time. It will not be the same as at the beginning of the operational cycle or not at the beginning but sometimes after the burn in period when already the number of transient events or number of reactor scrims already stabilized. Those who already started the operation of a nuclear power plant knows that at the beginning of the life cycle there are lots of reactor scrims and then the number of reactor scrims is lowering by the time and we were the same. So for the first unit we had, I don't know, maybe five reactor scrims in the first year of operation. Today we have one in ten years of operation. So this is the real effect of the maturing of the plant. However, there are other factors which are affecting the safety. Those are the modifications and design changes. Not in every plant there are such changes. In our plant we had lots of changes, lots of safety, so-called safety upgrading measures implemented. It was something like 60 or 70 safety upgrading measures were implemented since the beginning of the lifetime of the plant and each of them affected the safety very significantly. On the other hand the aging of the plant components is a factor which may increase the risk of the plant which may somewhat degrade the safety because there are aging components. By the time of course if you are using some components the wear out of the components causes the aging. So that also creates a problem with increasing number of equipment failures or increased frequency of the failures. With the increased frequency of the failures the unavailability of the component will be larger. Therefore the time when the component is unavailable is increasing by the increasing number of failures. And there are organizational and personal changes, definitely, yes, yes, yes, yes, that's right. Okay, this is a good question. The answer to this is that what we are estimating the aging. We have to follow the aging, whether the aging goes like it was designed or it is faster or lower. So in many cases unfortunately the aging may be faster than what was designed. And it can create problems with the lifetime of the equipment. So the actual design lifetime of the equipment is not exactly what it was designed for. Let me tell you one story with the reactor vessel of the VVR-440 reactor. So now today it is a well-known problem that the reactor vessel was very close to the core. And the fast neutron flux at the edge of the core was rather high and the effect on the reactor vessel wall was causing faster embrittlement of the reactor vessel than it was designed. So at the beginning of the operation this effect was not fully understood or was not fully known. For instance in Finland they already had to do some measures to recover the core, I mean to recover the reactor vessel to be able to operate through the lifetime of the reactor vessel. So there are some factors which accelerate the aging of the components, therefore it is very important to follow the age of especially those equipment which are important for safety. So now organizational and personal changes, well management changes because of aging of the people, 30, 40, 60 years of operation is long enough to have the personal change as well. Only new management will start their activity with changing the organization to fit into their, I mean to fit their taste. This was also in our case, there were several reorganizations of the plant personnel, there were several changes in terms of organizational units and of course there was a trial with the increasing cost of the, increasing labor costs, increasing salaries, those costs become significant contributors to the cost of the electric power production. Therefore there was an intention to try to minimize the number of staff at the plant and this is very much like in the other countries as well. So at the beginning we had like 5,000 people in the staff for four units, now we have two and a half or something like that, which is half of that. So these changes definitely will affect the safety. So because we have less people, we have different people and with the change of the people there are different knowledge, different training and so on and so on and there was a time even when we did not have the training, I mean education in the nuclear field because it was not needed. The market was saturated with nuclear experts, there is no need for newcomers. After a time it comes to a problem because people are also aging so they go retiring and then comes a problem, hey, there is a new young generation and we had to establish, we established in Paxch a school specialized on educating the new generation and today we get rid of that problem. So this is already a question of the knowledge management, which is a very popular terminology these days, knowledge management. The olds are going out with their experience, with their knowledge and nothing remains, just the documents. So this is a difficult issue and I guess most of the countries experience these difficulties if there was no education in the specialty of the nuclear field. So organizational personal changes are affecting the safety. Many of these changes are subject to licensing, which means some of these changes are already licensed by the regulator or are subject to licensing by the regulator. So you cannot do anything, I mean everything with your organization, this should fit into the operational needs and this is very important to assure the necessary number of and necessary qualification of the staff as we talked about it before. Then how funny the safety is changing with the development of safety analysis techniques, how it comes. Well, we analyzed something at the beginning and with the increasing knowledge and we are also developing with the knowledge, we have new techniques, we are discovering new phenomena which we haven't thought about. What we thought was safe before, it is not safe anymore today because something become clear which was not known at that time. So the safety analysis techniques with the development can show some new problem areas. So we are analyzing on a totally different way the safety problems as let's say 30 years ago. So it will happen with new plans as well, especially if we are trying to cover a 60-year period, just imagine 60 years. What was 60 years ago? Could you imagine the development, what has happened during these 60 years and then comes the question whether we are foreseeing that development for the next 60 years. Therefore it is important to follow the developments and do the reassessment of the safety with the new techniques. Changes of regulatory requirements, do they change? Of course they do, with the development of the safety analysis techniques with the development of the overall knowledge. Of course there are some political changes and how to say, public relations changes. The public, how funny it is, earlier we had less safe plans but the public acceptance was better than today when we have safer plans. Come on, this is a contradiction but this is true. So what can we do to satisfy the public? We need to increase or not increase but strengthen the regulatory requirements and the regulatory requirements are getting more and more strict by the time. Just a good example. We have different regulatory requirements to the old plans as to the new ones. By a factor of, by one order of magnitude we are lowering the frequency of the allowed, the maximum allowed core damages, the maximum allowed frequency of the core damages. We are lowering compared to the old nuclear power plants, one order of magnitude. So for the old reactors we are happy if the overall core damage frequency is somewhat 10 to the minus 4 per year or below 10 to the minus 4 per year. It would be unacceptable for new plants. We are expecting less than 10 to the minus 5 per year core damage frequency and the frequency of large releases we are, we also lowered down below 10 to the minus 6 per year, which is almost once in a million year. Come on, that's something which is, I mean we cannot imagine, once in a million years. So sooner or later we'll go down to once in a billion years and then it will be once in the lifetime of the earth. So that's which is already in the region of unbelievable. So this is how the progress is going. Today we have some set of regulatory requirements more or less harmonized on the international level. There are some discrepancies or there are some differences country by country, but more or less except the U.S. and France and a couple of big countries with large nuclear industry. The requirements are driven by the IAEA standards. And this is good because we can have sort of a common platform for the discussions on the international forums on this. Now due to new planned design developments and public expectations, I was talking about the public expectations, but it is interrelated with the strengthening of the regulatory requirements. And new planned design developments, just we had something at the beginning in terms of so-called seismic design of the plant. Seismic design considered an earthquake with the frequency of 10 to the minus 3 per year, 10 to the minus 3 per year, once in a 1,000 year. And then the general international requirements increased, I mean decreased this number to 10 to the minus 4 per year for the old plants. And it created a headache to the plant people how to strengthen the plant structures and components to survive 10 times, I mean earthquake which is more intense than the one which they were designed for at the beginning. And if you go to Pax and you see the plant, you will see some funny structures which were not there at the beginning around the plant buildings which have a role to strengthen the seismic resistance. And also inside the technology there are strengthened supports and some new structures built in in order to increase the seismic resistance. So today for the new plants it is not necessary because they are already satisfying the present requirements. I'm not sure about the future requirements because who knows where the future requirements will go. So it is necessary to assess the safety and demonstrate the acceptance of the safety time by time during the lifetime of the facility. That's clear. We are increasing just if you think regulatory requirements are changing, then you have to demonstrate the compliance with the new regulatory requirements and full stop. It may require a full re-evaluation of the safety as it was in our case. So that's something which is to be considered already at the beginning of the operation during the design. And as we have the design lifetime considerations, what we discussed just a couple of minutes ago, the design, during the design, the aging of the components has to be taken into account. Now the design lifetime of the plant is dependent on the non-replaceable plant component with the shortest design lifetime. I will repeat this in the next presentation as well because this is very important to understand what does it mean. So non-replaceable plant component with the shortest design lifetime. If it is the reactor vessel, because we are not replacing the reactor vessel, then this will limit the lifetime of the plant. If it is the steam generator because it is not replaceable, in some plants it is replaceable. But in the VVRs, for instance, these big horizontal steam generators are not replaceable. There is no way to replace them. So no technology to replace them. Therefore if I'm doing something with the steam generator which will end the lifetime of the steam generator, then full stop. This is the lifetime, end of the lifetime of the plant, of my plant because I'm not able to replace it. So this is how to understand the lifetime of the plant. Now, of course, for those components which are non-replaceable, I have to establish at the plant some control program which will define at any time the residual lifetime of that component to know where I am in time. So sometimes the material investigations, the investigation of the samples taken from the reactor to understand the progress of the embrittlement of the reactor vessel material may show me that, okay, so if the progress is such fast, then I have, I don't know, maximum 10 years of residual lifetime. After that I will have to stop the plant and so on and so on. And this is the same with the body of some pumps or the steam generator vessel and the steam generator structure. So that's why we are making, we are doing time by time some material investigation, okay. These are the so-called in-service inspection practice, okay. Now the design progress of aging effects of the non-replaceable components predetermines the lifetime of the plant, definitely. If the lifetime is 30 years, of course with the margin, there must be a safety margin which allows me to run the plant for 30 years. This is of course something important. But then I am investigating, I am doing such, or I am designing such core, let's say such core which has so-called low leakage core design. Low leakage core design means lowering the fast neutron flux at the edge, which is, if I am lowering, then the fluence of the fast, fast neutron fluence causing the embrittlement will be smaller and it may help me to increase the lifetime of the reactor vessel, okay. If it is the limiting factor. So and this is what we did, therefore the embrittlement didn't progress so fast, therefore we could increase or extend the service life of the plant. We licensed 20 years extra operational life for our plant. But we had to do these investigations and we had to justify that this allows that. Also allowed by the design maximum number of the cycle, cycles of specific events may be a lifetime limiting factor. I mention it especially, we try to not to concentrate on the allowed number of cycles, load cycles, but there are load cycles. Let's say if we are designing a plant to be able to follow the load, the load following characteristics, it will require to determine how many times I can change 1%, how many times I can change, I don't know, 50% and 20% and so on and so on, so that the operator was able to make the maneuvers necessary for the load following. But as soon as it expires, you cannot do anything.  So you can operate either only in base load operation or you have to stop the plant. That's it. So now we will come to this. It is essential to follow the development of the limiting factors to determine or to demonstrate the safety during the residual lifetime. Now the prime responsibility for the safety rest with the person or organization responsible for the facilities and activities that give rise to radiation risk, which means the operating organization. So the designer did his best, they will specify the life limiting factors, they will specify many other things, and then the responsibility of the safety will remain with the operating organization. So this is the operating organization who has to do those investigations which are needed to demonstrate the plant safety. Then the operating organization shall establish a formal system for ensuring the continuing safety of the plant design through the lifetime of the nuclear power plant. This is in the SSR 2 slash 1, and probably this requirement 3 has already been mentioned, but it will be mentioned another time during this day. So what about the modifications and design changes? During the operation of the nuclear power plant, the person performs technological changes and or organizational changes. Sometimes we have to. There are requirements to do that. There are some new developments which shows the necessity of doing so, or simply we have a better solution, or we discovered some weaknesses in the design. We had, again, I can give you examples on any of these because we have a nice experience with those changes, those design changes we had to perform. Like the one which was mentioned by Alec yesterday, that when the diesel generator starts, you cannot immediately load the diesel generator with all the consumers. You have to do some step-by-step loading program. You have to follow some step-by-step loading program. And that's okay. By design it is said so that if the large, large brake rocker in the primary circuit occurs, then the diesel generator will start. If we are losing the power, diesel generator will start. And in 20 seconds the diesel generator will be already on a level where the step-by-step loading program can start. Now it appeared that this 20 seconds is too long because after large brake rocker accompanied with the loss of off-site power, the pressure in the primary circuit will drop down below 150 degrees. So the pressure will go down so that the primary coolant temperature will be below 150 degrees. Which means another step-by-step loading program would start just because there are distinguished systems for the low power or shutdown cases and full power cases. So the system thought that the primary parameters belong to a shutdown state, therefore a totally different set of systems would have started. So it created, of course, everybody was surprised at how it comes to design deficiency. Let's do something. First question was to understand whether this event will be accompanied with loss of power or not. Then if it is accompanied with loss of power, then we make a delay with the consideration of what kind of step-by-step loading program should start. So we had to modify the logic of the step-by-step loading program in order to avoid such situation. And there are other stuff which comes from the experience of investigating the results of the safety analysis cases. So these changes may affect the plant's safety, therefore the safety of these changes should be justified and demonstrated depending on the regulatory requirements. Any modification at the plant has to be categorized according to their safety relevance. And for the higher safety classification or categorizations, let's say categories, not classification, not classes, categorization. So if I classify or categorize a modification to be category one, then it will need a special licensing process. So of course the categorization will depend on the safety significance of the change I am doing. The regulatory body requires, very strictly requires the categorization and the licensing process according to the category after the end. The national regulation should specify the licensing requirements of any plant technical or organizational modification that has relevance to the safety. These requirements cover also the safety analysis of the modification. So safety analysis requirements are also specified for such modifications. Now comes the question that do I reanalyze all the safety analysis after each modification? No. They are cumulated and then comes a time when I have to submit a so-called periodic safety review where I'm also submitting the safety assessment which considers the cumulated changes. And here comes the periodic safety review discussion where these are routine reviews of usually routine reviews of nuclear power plant operation including reviews of modifications to hardware and procedures, significant events, operating experience, plant management and personal competence and special reviews following major events of safety significance are preliminary means of ensuring the safety. This is okay. This is what we understand. Now some member states have initiated systematic safety reassessments termed periodic safety review. Some member states, more and more member states. Let's say so because not everybody is having, not every country is requiring such periodic safety review. The periodic safety review is assessing the cumulative effects of the plant aging and plant modifications, operating experience, technical development and sighting aspects. So we are re-evaluating also the sighting aspects which we were talking about yesterday. Yes, it was yesterday. The periodic safety review, the PSR includes an assessment of plant design and operation against applicable current safety standards and operating practices and has the objective of ensuring a high level of safety through the plant's operating life. Now this is what we are doing. We are reassessing the safety according to our actual plant status, actual environmental sighting, design and so on and so on, comparing them or justifying them, justifying the compliance of them with the actual regulatory requirements. And with this, of course, it will cause increasing safety over the lifetime of the plant. But it will cause, of course, lots of investment into safety improvements and into the safety analysis to be performed. Well nuclear power plant is producing electric energy so there is a source of these resources therefore we should not be, how to say, we should not take care of the cost of such periodic safety reviews. Then again, okay, so the safety of nuclear power plants, the commissioning and operation, this is SSR 2 slash 2 says about the periodic safety review which is a systematic safety assessment of the plant in accordance with the regulatory requirements shall be performed by the operating organization through the plant operating lifetime. We do account taken of operating experience and significant new safety related information from relevant sources. And the other safety guide which is issued by the IAEA is the periodic safety review for nuclear power plants. So this is the SRG-25 and it contains the content requirements for the periodic safety review reports and it contains the content of the periodic safety review assessment itself. It says although the operating nuclear power plants are subject to routine and special safety reviewed, such reviews are generally not sufficiently comprehensive to meet this requirement. Which means this requirement which said systematic assessment should be performed, this special safety reviews are not sufficiently comprehensive. This is what it says therefore a periodic safety review should be done. And this is the suitable tool to perform the sufficiently comprehensive assessment of safety during the lifetime. And this SSG or this specific safety guide specifies the rationale of the periodic safety reviews with a 10-year period. They say that 10-year period is sufficient. Why not five? Why not two? Why not three? Okay, we are not able to just continuously doing periodic safety reviews. The periodic safety review process is a long and time-consuming process, this is one part. And 10 years considered to be enough long to see the changes, to see the changes of the safety with the accumulated effect of the modifications during that period. And it seems to be short enough not to miss significant safety degradations. So this is the rationale and basically this 10-year period, 10-12-year period is accepted by the member states and it is followed. Now the changes in international safety standards, operating practices or technology underlying scientific knowledge or analytical techniques is maybe significant enough to be considered. The potential for cumulative effects of plant modifications to adversely affect the safety or the accessibility and usability of the safety documentation. Identification of significant aging effects or trends will also be identifiable, accumulation of relevant operating experience, changes in how the plant is or will be operated, changes in the natural, industrial and demographic environment in the vicinity of the plant, changes in staffing levels or the experience of the staff, changes in the management structures and procedures of the plant operating organization. So these are all explaining why about 10 years. This can have different purposes. The systematic safety assessment carried out at regular intervals, support the decision-making process for license renewal, support of the decision-making process for long-term operation. Well, the regulation in the different countries is very much different in relation with the license renewal. There are some countries where the license has to be renewed every year. There are some countries where the license renewal is switched to the periodic safety review. And there are some countries where when the operating license is issued at the beginning of the lifetime of the plant, it is valid for the whole lifetime duration. So depending on in which country we are, the purpose of doing a periodic safety review can be different. The objective of the periodic safety review is to determine the adequacy and effectiveness of the arrangements and structures, systems and components that are in place to ensure the plant safety until the next periodic safety review or where appropriate until the end of the plant operation. That is, if the nuclear power plant sees operation before the next PSR is due. So we are trying to assess the safety for the next period, till the next periodic safety review. We have to justify the safety, justify that the aging mechanisms are not jeopardizing the safety till the next periodic safety review. And the regulatory body can be sure that, okay, we accept the plant operation for the next 10 years till the next periodic safety review. Of course, if the plant lifetime expires within this period, then the safety should be ensured till the end of the lifetime of the plant. The other objectives, the objective of the PSR is to determine the extent to which the plant conforms to current national and or international safety standards and operating practices. Just as you can see changes in the IAEA standards, they are reviewed time by time and some new safety standards are coming out. Especially the question are related to the new safety standards. But as you could see in the last 30 years, how the structure of the safety standards at the IAEA has changed. So we are now renaming the safety standards to one, something was NSR, something now we have SR, SSR and so on and so on. So also the structure is changing, definitely the content is changing. Also with these changes, standard changes, the international acceptance is changing for the operating plants. Therefore we have to determine the extent to which the plant conforms the current international safety standards. Given the safety performance and time for the implementation, it may happen that during the period between two periodic safety reviews, only the design started over change. And we already include in the new periodic safety review report as if the change has already been implemented to show what will be for the next 10-year period. So also the extent to which the safety documentation including the licensing basis remains valid. These are what we have to analyze. Now how do we do that? How do we do that? This special safety guide specifies so-called safety factors relating to the plant. Here we had in the original safety analysis report, I don't know, one to 19 chapters describing each chapter its specific topic. Here we have safety factors analyzed. The first safety factor, safety factor one is the plant design. To determine the adequacy of the design of the nuclear power plant and its documentation by assessment against the current licensing basis. And national and international standards, requirements and practices, yes. So the current design to the current requirement. Then safety factor two, actual condition of structures, systems, and components as well as the SSTs important to safety. So this will contain the assessment to determine the actual condition of SSTs important to safety and so to consider whether they are capable and adequate to meet design requirements. At least until the next periodic safety review. In addition, the review should verify that the condition of the SSTs important to safety is properly documented as well as reviewing the ongoing maintenance, surveillance, and in-service inspection programs as applicable. So what do I analyze when I'm doing the in-service inspection of a pipeline? The third one measure, well, the residual wall sickness. So we are measuring the residual wall sickness because we are trying to identify those cracks and the growth of the cracks inside the wall which will then determine the decrease of the effective wall sickness of the pipe. Now of course, there will be a critical wall sickness below which we will not withstand the pressure inside. So I am analyzing the speed of the growth of the crack. And I'm predicting for the next 10 years I have to justify that I still will have a sufficient margin in the wall thickness in order to operate without any problems. So this is what the in-service inspection is usually doing at the nuclear power plant. So in other words, the aging of the pipeline is measured and predicted for the next period. And this is the actual condition of structures and systems and components. For active components, the trends of the failure rates, how often they are failing or vibration in a pump, increase of vibration in the pump and the region, the pressure region where this vibration is going on, how the pump would behave in the real actuation when it was needed, will it perform, will it still perform its function or it will fail. So these are the investigations which I have to include in the justification of compliance with the requirement. Equipment qualification. Now we had a lecture about equipment qualification. We have to reassess the equipment qualification in order to determine whether the plant equipment important to safety has been properly qualified according to some new well knowledge because as Alex said, the equipment qualification is not just a one-shot project. We have to revisit and reconsider the equipment qualification. So including the environmental conditions and whether this qualification is being maintained through an adequate program of maintenance, inspection and testing that provides confidence in the delivery of the safety functions until at least the next periodic safety review. Then safety factor four is the aging. You can see that these safety factors are somehow interrelated. So there is some cross-cutting areas where I am analyzing something at one safety factor it comes back again in the other like aging to determine whether aging effects affecting the SSC is important to safety are being effectively managed and whether an effective aging management program is in place so that all required safety functions be delivered, it is repeated many times. Deterministic safety analysis. We have to determine whether the existing safety, deterministic safety analysis are complete and are still valid or I have to do something, I have to redo some of them or all of them depending on all kinds of design changes, organizational changes, whatever. So all the changes has to be considered and also I have to consider the new developments in the analysis techniques. So earlier we had how it was called the original deterministic code which the original design took into account, it was thermo-dynamica, something, I don't know. Today there is a much more developed program and also we used relapse and other deterministic codes which are using more precise or more verified correlations and so on and so on. So definitely for those codes, using those codes the conclusions from the analysis may change drastically whereas we thought that, okay, the temperature, the cladding temperature will go up to 800 degrees during a process. The new calculations may show that at 400 degrees the temperature starts decreasing and so on and so on. We can see easily such changes in the analysis results. So probabilistic safety assessment, to determine to what extent the existing PSA is complete and remains valid, again the same. If I'm changing something in the design, in the system, I'm making some kind of physical separation of pipelines which were not there before then definitely the assumptions I did during the probabilistic safety analysis will change because I can be sure that the structure of that pipeline will not affect the other pipeline because there is that thick concrete wall between the two which did not exist at the beginning. Hazard analysis is also the 7th safety factor. Yes, Chapter 15, Chapter 15 of the final safety analysis report, yes. So we'll have to review all those safety, deterministic safety analysis which are included in the safety analysis report, the final safety analysis report. We have to update the final safety analysis report according to the changes what we discovered. Okay, I'm talking about Chapter 15 according to the US terminology which is coming from but it may be different to the IAEA terminology I don't remember. So the deterministic safety analysis or the safety analysis as a whole including the deterministic and probabilistic safety analysis should be reviewed. Okay, so if the safety analysis is in Chapter 5 or 6, then I have to, yes, just. Someone from the Chapter 15, okay. Talking about the reactor, the floor and talking about. Oh, I see, okay, yes, yes. They may be included. Yes. Are included in Chapter 15 and can. But they must be included in, so there is a reference between, there is a reference from Chapter 5 or 6 to the Chapter 15, but the basis for that is the Chapter 15. The safety analysis chapter is the one which, yeah. In any case, the final safety analysis review is updated with the information included in the periodic safety review, okay. So I will have a new final safety analysis, the final safety analysis report is a leaving document together with the plant safety. So it is not a constant document which was created at the beginning of the lifetime of the plant when we issued the operating license, but it will be changing by those changes which are in the periodic safety review, okay. Hazard analysis. The hazard analysis is also to be reviewed because there are also changes in the resistance against some hazards. We did awful lot of work to separate the original cables which were installed at the plant. We had at the beginning cable trays with that bunch of cables and nobody knew what kind of cables were there.  It was almost impossible. So we decided to first put everything in order, which means separate the safety train cables from all the rest, which was easier to disconnect those cables which were there and rebuild new cable routing, okay. After that, we already knew that the physical separation of those cables are there and we can do the fire hazard study, internal fire hazard study. So this kind of analysis should be also included in the periodic safety review in order to show either the relevance of the old study or to analyze the new situation. Then safety performance. It is to determine whether the plant's safety performance indicators and records of operating experience, including the evaluation of root causes of plant events, indicate any need for safety improvements. Do you know what are the safety performance indicators? Do you have it in your plants? Safety performance indicators? Safety performance indicators are those number or numerical values which characterize some part of the safety. So a performance indicator system would somehow characterize the behavior of the plant's safety in terms of numbers. So it is for the managers to show that the number of reactor scrams in the last 10 years are remained below one or something like that or the radioactive effluents were that much and that much in the last year. So these are yearly evaluated or quarterly even and these performance indicators can indicate some deficiencies, some trends, some changes and so on and so on. Therefore the safety performance in terms of performance indicators should be investigated and should be reported in the periodic safety review report. Some regulatory bodies require the usage of a plant's safety performance indicator system and in some countries the reporting of the safety performance indicators quarterly or yearly is required by the regulatory body. So to be able to follow the plant safety performance. Then of course the records of operating experience and the root causes of plant events depending on what kind of events are to be analyzed by root cause analysis. Not all the events of the plant are analyzed by root cause analysis but there are some where I want to know what was the root cause of that particular occurrence. I have to perform root cause analysis and the root cause analysis will indicate, will show me what was the root cause for that particular occurrence. It is not easy, let me say so. It is not easy because some occurrence may have potentially different causes. So what has been the root cause in the particular case? If we are closer in time to the event we are very likely able to identify what was the root cause. Otherwise later, a year later or two years later just you want to analyze what was the root cause. You are losing already so much information that you can already approach with a probabilistic approach the causes. And you can already just identify the contributors to the events of the different causes. So the root causes will give us lots of interesting information and it may indicate the need for some safety improvements. Then the use of experience from other plants and research findings. Other plants and research findings is something which needs the data investigation or information collection from sources which contains the international experience, operating experience. VANO, the World Association of Nuclear Operators, runs such system which collects the operating experience in terms of incident reporting, also event reporting, then the performance indicators and so on and so on. And all the members of VANO will be able to access this information. The IAEA is running the IRS system, incident reporting system, which will also be a source for such international experience. And there are some regional so-called information collection systems like system of some owners group members or more broad international systems. So there are lots of ways of collecting this information from. And the plant operator is part of some of these organizations, therefore they will be accessed to this information. And they have to use this information in order to see or to determine whether there is adequate feedback of relevant experience from other nuclear power plants and from the findings of research and whether this is used to introduce reasonable and practical safety improvements at the plant or in the operating organization. So if I see that the other nuclear power plant, somewhere in another country, similar nuclear power plant, discovers some safety deficiency and it comes into the operating experience collection system. I also have to take care about this information. I also have to investigate whether it is relevant to my plant. And if it is relevant to my plant, I have to use it. I have to use this. So this is the feedback of the operating experience from other operating organizations. Then safety factors, organization, management system, and safety culture. This is something soft topic, let's say so. Usually not treated very seriously, however, the organizational factors, the management systems, and the safety culture, evaluation of the safety culture at the plant is very important. Unfortunately, the assessment of these safety factors is based on some kind of self-assessment, some self-assessment techniques, which means I am analyzing, I am assessing myself, my performance, and trying to find out whether I did something wrong. It is very difficult to acknowledge that I did something wrong. And especially when it goes to some periodic safety review report, which goes to the regulator. So I'm still a little bit skeptic about the truth of the content of this safety factor in the different periodic safety reviews. In an open environment where the management and the people are open to, and they acknowledge that they can do mistakes, then the acknowledgement of being able to do mistakes, this is important. In such an environment, it is easier. But in other cases, when it may have some bad consequences, bad personal or organizational consequences, it is difficult. So it is to determine whether the organization, management system, and safety culture are adequate and effective for ensuring the safe operation of the nuclear power plant. Now comes the question. If there was some bad event at the nuclear power plant, which clearly shows some evidence that it was due to some organizational factors, then this should appear here in this chapter or under this safety factor. So that is really difficult. Then comes the procedures to determine whether the operating organization processes for managing, implementing, and adhering to operating and working procedures and for maintaining compliance with the operational limits and conditions and regulatory requirements are adequate and effective to ensure the safety. So procedures and organizational processes. These are those processes which are regulated by the procedures in the maintenance, in operation, and other areas. So these are administrative procedures, and I have to assess those whether they are serving to help keeping the safety on the required level or not, or there is some deficiency. Sometimes it happens that such audit will indicate some deficiencies which affects the safety. Therefore, those results of those audits should go into this safety factor. And human factors. This is to evaluate the various human factors that may affect the safe operation of the nuclear power plant and to seek to identify improvements that are reasonable and practicable. Human factors we were talking about and we talked about the human factor engineering requirements and elements. All this should be discussed here. Then factors relating to management, emergency planning. It is to determine whether the operating organization has in place adequate plans, staff, facilities, and equipment for dealing with emergencies. And whether the operating organization's arrangements have been adequately coordinated with the arrangements of local and national authorities and are regularly exercised. Such emergency drills, let's call it like that, are time by time organized on the site. And time by time in cooperation with the local authorities, they are organizing such emergency drills in the region which may be affected by the nuclear power plant. And the results of these drills and the description of what are those facilities, equipment and staff and so on should be demonstrated that they are in compliance with the actual regulations. So this is an interesting topic again because people usually don't like to participate in such drills, especially if you have nothing to do with the nuclear power plant. So I remember when we lived in Pax, they distributed these gas masks for the children. Not for the adults, but for the children. In case something happens, and my little kids were so happy, they received a new toy. So they wanted to try it all the time. But then we said, okay, guys, this is not for playing, we took them away and put on the shelf just for the case. But there were some drills where, yes, they had to use it, so yes. So we were not that happy, but they took it as an interesting game. Safety factors relating to the environment. Now the radiological impact of the facility to the environment should be discussed to determine whether the operating organization has an adequate and effective program for monitoring the radiological impact of the plant to the environment, which ensures that the emissions are properly controlled and are as low as reasonable achievable, ALLARA. So you know what ALLARA means, so everybody knows what ALLARA means, I think. So during normal operation, the releases should be ALLARA. So that's it, that's the message, and you have to justify it, you have to show it. So basically in our plant they can demonstrate that the releases from the Paxchia nuclear power plant is lower than the radioactive releases of the conventional power plant near our settlement where we are living, which is funny but true. So for some reason the radioactive releases of that traditional power plant in normal operation is almost one order of magnitude higher than the gas releases of the nuclear power plant, which is a good news to the nuclear power plant, but not a good news for the people who are living though it is well below the limits, of course, so it is not bothering anybody, but the measurements show such difference, okay. So basically this is the 14 so-called safety factors to be analyzed. Now there is one more important issue which is the review of the physical security of the nuclear power plant. It is generally not included in the periodic safety review. Physical security is something very sensitive, so it should be kept in secret and so on and so on. Of course there should be a review, periodic review and with the new developments definitely the security should increase, but it is not generally included in the PSR because of the sensitivity of the subject and the need to ensure confidentiality. This should be reviewed periodically by the appropriate national authorities, so there are dedicated authorities who will do this review. However, some operating organizations may decide to review physical security as a separate safety factor in the periodic safety review. We could see in some countries in the periodic safety review discussion of the review of the physical security or the physical protection. Okay, now the PSR findings, definitely everybody would like to see, so why do we do this review? To formulate the findings, to formulate the issues and of course for political reason we are formulating first the positive findings that this has improved, this has been better and this become more powerful and so on and so on. So that is the strength of which we are indicated, where current practice is equivalent to good practices as established in the current codes and standards and so on. But the negative findings, which are the deviations where the current practices are not of a standard equivalent to current codes and standards or industry practices or do not meet the current licensing basis or inconsistent with operational documentation of the plant or operating procedures. So there are three types of deviations in the first for which no reasonable and practicable improvements can be identified. There are such design deficiencies which simply I cannot do anything or some other problems which I cannot do anything. Whatever I invest in it will remain. Therefore, this deviation has to be indicated and later it will be decided by the regulator whether they can live with it or not. If not, they may even obliged to shut down the plant. But in most of the cases under some conditions they allow continued operation. Then there are deviations for which identified improvements are not considered necessary. Well, it's interesting to have such deviations which you don't have to care about. And deviations for which safety improvements are considered necessary. Now those deviations will be a question of licensing and a licensing issue. Then the regulator will tell you that within the next five years period you have to solve the problem and declare the problem be solved. Okay. And these are the periodic safety review tasks. I will skip it. You know, sorry. There are four points which to be mentioned. Preparation, this is a long time process because you have to form a group of people. You have to form a project which will prepare the periodic safety review report. Also, which will perform those necessary safety analysis tasks which are included in the periodic safety review. Conduct of the periodic safety review when you are executing it. This is also a long time process. All together, actually, the preparation and the execution can be more than two years according to our experience. And the regulatory review of the findings with the regulatory decisions. And then comes the finalization of the integrated implementation plan where you want to get rid of the negative findings. You are describing the implementation plan, how to proceed in the next two, three, five years period in order to improve the safety or in order to be on the level required at this time. Okay. So basically, this was the periodic safety review presentation.


Aloha, I'm Stan Osserman, host of Think Tech's Stand the Energy Man every Friday on Think Tech Hawaii at noon. Think Tech's important in our community because it does take care of things that matter in our community. We're the people that bring the solutions and bring the ideas to the public so they can think about them and make a difference in our state. And for the first time, Think Tech Hawaii is participating in an online web-based fundraising campaign to raise $40,000 and give thanks to Think Tech. We will run only during the month of November and you can help. Please donate what you can so that Think Tech Hawaii can continue to raise public awareness and promote civic engagement through free programming like the show that I do. I've already made my donation, I look forward to yours. Please send your tax deductible, that's important, tax deductible contribution by going to the website, www.thanksforthinktech.causevox, that's C-A-U-S-E-V-O-X.com, so www.thanks-to-Think-Tech.cause-vox.com. On behalf of the community enriched by Think Tech Hawaii and it's 30 plus weekly shows, thank you for your generosity.


Hello everyone, welcome to my session Dapper Unleashed, Accelerating Microservice Development. First of all, I would like to thank everyone behind Dapper Days 2024. I think it's a great organization and I'm really honored to be part of this selection of great sessions. I'm really looking forward to follow up on all the sessions because I think they're very relevant to the topic. My session is about practical implementation and practical application of Dapper in real projects. In my session, I would like to give a developer perspective on how to use Dapper on a real development team and how Dapper can help that development team to produce more reliable projects faster and of course with better quality. It's very difficult to explore the whole journey in 30 minutes, so therefore I will focus on the most important aspects from my perspective. Of course, you are very welcome to reach out with more questions and discussion. Before I dive in, I would like to introduce myself. I am Miroslav Janowski, Technical Director at INE Group. INE Group is a Nordic champion in providing IT solutions for the industrial world. As a technical director, I'm responsible for cloud, web and mobile development. I hold an engineering doctorate title from the Young Hoven University of Technology. Almost 17 years of experience with .NET, hate and love relationship, more of it, it's love and much less it's hate. And I've had different titles in my software engineering career, starting as a junior engineer, through technical manager and now technical director. Okay, now we can start since you know me. Now we can start. The agenda for my session is the following. First of all, I will introduce to a case study, a real project that has been simplified for the purpose of this presentation. This project originally started without Dapper and due to our curiosity and passion for quite a lot of software engineering, we have explored Dapper and its possibilities. Once you are introduced to the case study, I will explore the non-Dapper version of the project and then I will vaporize it. During that, I will show the source C-sharp source code and point to only the most important code snippets from the Dapper perspective. Finally, I will elaborate on one way as well from my team's perspective and what are our next steps. Case study. Built an AI-supported service for Ethetech assignment evaluation. For one of our first favorite customers, we had to build an AI-supported service for formative assessment of students' products and homework and also give suggestions for further development. Our customer is basically Ethetech startup that wants to completely change the education process by establishing creative and engaging learning for a better world. The customer has an ecosystem of several different web applications for creativity and collaboration. With the applications, the students can create different type of content, videos, books, mind maps, and so on. And of course, they can collaborate on this content interactively. Init Group is a technology partner for this customer and we are responsible for their accelerated agile development. Very recently, inspired by the great success of GPT, the customer wanted to create an AI-driven module for formative assess assessment of student products and also to give suggestions for their further development. Very often, the students have no inspiration and they get stuck into their creativity. So we would like to use GPT and AI basically to give them and to inspire them so they can be more creative and more productive. The idea is that the students create content of various types. Basically, they can use the older, different products from the startup to create audios, videos, mind maps, text, and so on. And then they can ask GPT for feedback or for further development of ideas. For that purpose, we have to transform everything the student has produced into text, then create a form and send it to GPT. Since this is startup, we know that everything must be production ready from day one. That means at least scalability, resilience, and security have to be treated with the same priority as the functional requirements. There were we went for microservice architecture from the very beginning. We have identified three microservices or three microservice application. The first one is ingestion service. The ingestion service is responsible for receiving requests from students and teachers. The ingestion service has one single HTTP endpoint and when a request is received containing all the multimedia content, text, audio, video, and so on, it is stored into a command prompt storage. And then the request is sent by reference to the next microservice. Of course, it's sent via queue. The transformation service is the one in the middle. That one is responsible for transforming the request by transforming everything non-text to text. This service used combination of various cognitive services as well as domain knowledge. And when the request is being transformed, the final result is being stored into a prompt storage, again into the common prompt storage, and also sent further by reference to the next microservice. The final microservice is basically the extraction service and this service is responsible for creating a prompt, including domain knowledge, sending that prompt to GPT service. And then once the result is ready, the result is stored into the common prompt storage and is forwarded back to the requester. One comment about the common prompt storage, you might argue that this is not a valid microservice architecture because all the three microservices, they share the same database or the same data storage. In this case, that is not really a valid argument because we use serverless prompt storage and that is Cosmos DB, basically, technology with autoscale that can support scalability in theory, infinite scalability and avoid the problems or the effects of a noisy neighbor. So even if there is a noisy microservice, ingestion, transformation or ingestion, it doesn't really matter because Cosmos DB has to handle that out of the box. This is the current architecture implemented in Azure and as it is being shown now, it runs in production at this moment. So you can see we have the three microservice applications implemented in .NET and they run in Docker containers in Azure container using Azure container services. We have queues, Azure service bus queues, between them and we have Cosmos DB as a common storage. Of course, there are many more services that are being queues like the cognitive services, open AI, application insights, key vaults, Azure monitor and so on and so on. Before we dive into the non-daproversion source code, I want to emphasize some important points for this session. Namely, in the non-daproversion, all the microservices must know how to connect to Azure Key Vault, how to read and write to Azure Cosmos DB and how to send and receive queues or requests to Azure service bus queues. So basically all these three services, they have to have these three knowledges or these three know-hows in order to complete their tasks. This common knowledge is basically manifested into boilerplate source code that is dragged along through the application lifecycle. And as such, it requires continuous maintenance, updates and tests, otherwise it will become a technical debt. Okay, now let's see the non-daproversion source code. One note here is that for the purpose of this session, I have all the projects living into a single repository while the production version or the real project, it's a multi-repo organization, has a multi-repo organization where each microservice lives into its own repository and has its own CI CD pipelines. Okay, in the non-daproversion, we have five projects and that is the API project, which is basically the ingestion, responsible for receiving requests. We have the transformation service, we have the extraction service and we have two more additional projects and that is domain model project, which holds all the domain entities that we need for this solution. And we have common service, which basically implements the common services that are needed across the microservice applications. In the common service, we have implementation on how to store and how to read values from Cosmos DB. And we do have a Q service that is responsible for sending items into Azure Service Bus Q. It's important that this project is being shared among all the three microservice application and that is basically the one that has the knowledge on how to use these services or how to use the third-party services that we need. Okay, the API project, it has only one controller and what it does, it waits for new requests when a new request is coming. It is basically executing internal prompt service and that service, what it does, it sends, it adds some logs, of course, and then it stores the request into the storage service and send the request into the queue. Then we have the transformation service. The transformation service is basically a console application that continuously listens for new changes on the queue and whenever there is a new change on the queue, it basically transforms the new items. So it gets the queue message, it reads all the details from the storage service, it does some magic, of course, then update the log states and again store to the storage and send to the next queue in the pipeline. And of course, we have the extraction service which is pretty similar. It has extraction service implementation in it and what it does, it waits for a queue message and whenever there is a new queue message, it gets all the details from the storage, executes open AI call, updates the log states and of course stores the final result into the prompt or into the storage service again. And as you can see, all these three services, they have basically implementation or basically initialization and injection of the common service and that is being implemented here. So into the API, we do have these two methods, register storage service and register queue service and what they do, they create a new Key Vault Inst Client, then they read the Cosmos DB connection string, they create new database connection and they inject that into a storage service. It is very similar with the queues. Again, we read from the Key Vault name, we create Key Vault client, we read the service bus connection string and create queue service. So what we get here, we get around 30 lines of code that are being used for creating and injecting the common services. It's pretty much similar with the other two microservices in the transformation service, we have the same case. We have initialized async, which is again around 30 lines of code that is being used for creating the common services and their appropriate injection. And of course, we have the same thing for the extraction service. One thing that I want to note here is the docker-compose file. So the docker-compose file is quite similar or quite simple because we have three microservices which are represented by three docker files and these three are created into the docker-compose file. Okay, so that was the non-dapper version source code. Now the next thing is to vaporize this solution. So let's do it. Before I jump in into the source code, I would like to give some elaboration on the steps that I'm going to do. So in the non-dapper version, as you already have seen that all three microservices, they have to have implementation of the common service, services that basically implement talking to Cosmos DB and talking to Azure Service Bus Qs. In the docker version, what we will achieve basically, we will get rid of the common services. So that is the first and most important benefit of the dockerization. So we remove the common services that have implementation on how to talk to Cosmos DB and how to send and receive a request to the service bus queue. And then instead of that, we get one docker sidecar container next to our three microservices. So the depreciation basically starts with one big deal and that is we don't need the common services anymore. Technically in source code, with source code language, it means one project less, no service initialization and no injection. So those 30 lines of injection that we have to copy from one microservice to another. And of course, no third party SDK dependencies. So our solution will not depend anymore on SDK for Cosmos DB and for Azure service bus. Of course, we reduce the source code, but on the other side, we will have to increase the configuration. So we will have to introduce the docker components. And of course, we will get more complex docker compose file, at least for local development. So when I was trying to explain to the developers in my team, when we do docker transition, we basically remove source code with configuration. And that source code is pretty much boilerplate source code that we still have to maintain. And if we don't do that, it will become a technical debt. And with docker, basically we get rid of that boilerplate source code that can become a problem after some time. And we move that complexity into configuration and config files. Because I mentioned Azure and this is running in Azure and we are using Azure as a cloud provider. So all these three services are basically implemented with Azure. Our three microservices, or our three microservice applications, they have Dapper sidecar running next to them that has knowledge on how to communicate to Key Vault, how to read and write items to the Cosmos DB and also how to send requests to Service Bus Q. So now let's see the Dapper version source code. Okay, now let's see the Dapper version of the source code, of the project. So as I already mentioned, we don't have the common service and that is one big win. So we do have removed the Q service and the storage service and we also removed their dependence. So I will now open the API, the ingestion service, and I will open the dependency injection or the program.cs file. And we did remove all that 30 something clients of code where we create new instance of the Q service and injection and also from the storage service. And instead of that, we do have only one single line at Dapper client. Going further in the prompt service, instead of injecting the Q service and the storage service we have injected only the Dapper client. And when we process new prompts, basically there is no big difference in the numbers of source code lines, but there is a difference in the way how do we save prompt and how do we send them to the next Q in the pipeline. Okay, another big thing and another big transformation is in the type of the project. So in the non Dapper version, we have the extraction service and the transformation service as a console application. In this case, in the Dapper version, they are APIs. Why? Because now the Dapper sidecar container basically takes over the responsibility for continuously listening for new changes or for new items on the queue. And whenever there is a new item in the queue, they create HTTP call to our application to inform us that there is a new item in the queue. So the transformation service now is a web API solution and it has a prompt controller. And in that prompt controller, whenever there is a new item in the queue, the Dapper sidecar container detects that item and send us VHTTP to our prompt controller. So this definition here basically says that this controller continuously listen, I mean, this controller will accept new items from the sub-sub-sub component and from the transform queue. Whenever we have a new item there that is being sent to the transformation service. The transformation service, it's also quite simplified but not too much because there is a difference in the injection. We don't inject the Dapper, the queue service and the storage service, but we do inject the Dapper client. Of course, the difference here is that we don't call the storage service and the queue service, but we call the Dapper client to save state and to publish events. The same goes for extraction service and I will skip that elaboration. What I want to elaborate is the Docker compose file. As I mentioned, we do have more complex Docker compose file. Why? Because for each of our services, now we have to register the sidecar or the Dapper container. So instead of three, now we have six services registered in the Docker compose file. Again, this is for local development. For cloud development, there are different configurations that I will skip. They that are not part of this session. I would like to emphasize couple of things about the components. I really like the simplicity and the configurability of the components. They're very simple to use and out of the box. So this is the Azure Key Vault component. And also, for instance, in the PubSub component, this is how we use the secret store. So we tell that we use this secret store and we tell that if you want to use this queue, the connection string for this queue is basically a secret key reference in the secret store. So this is very elegant and very simple to use. And of course, this is the prompt store, the Cosmos DB configuration. One thing that I want to emphasize here is the key prefix feature. Basically with the key prefix feature, we were able to reuse the same prompt service, but also the same items that we store into the prompt service from all the three microservice applications. So the key prefix basically makes a distinguish whether do we share the items across all the microservices or not. What we wanted to achieve is basically that our prompts from the ingestion service, they have to be available and reachable also for the extraction service and also from the transformation service. By using this feature, we basically enabled that in a very elegant solution again in a very elegant way. And one more thing that I want to mention here is basically how Dapper utilizes the metadata. So the partition key. Partition key is very important thing to know and especially when you design a new Cosmos DB domain model. So what it does, Dapper basically enables through the metadata to set the proper partition key into the save state, I think, call method. So this is very, very good and very efficient. In our case, we have decided to use the type as a partition key. And when we get a new prompt, we get the prompt type and when we send save state, we basically set the partition key to type and that's how we store the new items into the storage service. So that was the source code overview of the Dapper version. As a, because of my R&D background, I really want to get deeper into the numbers every now and then. So I did static source code analysis on the both projects with Dapper and without Dapper. We were, I was following three parameters, maintainability index, cyclomatic complexity and lines of executable codes. On the maintainability index, we did not get significant reduction because we pretty much got the same index or the same numbers. Why is that? Because these projects, they don't have the business logic inside them. So it's quite clean and pristine source code. On the cyclomatic complexity, we got around 10% reduction, which is quite good and I'm really happy with that. And I think the main reasons for that is that we removed the dependency injection for the common services. And the most important thing is the reduction of the lines of executable source code. We got first 40% reduction for this project and that is great number, but also of course, this project is not a real project and does not have all the business logic that is being implemented in the real project. For the real project, we get around 22% reduction on the lines of executable source code. But in that solution, we don't use Dapper, for instance, for AI component, for communication to open AI service. Now I know that there is a Dapper component for that. So with more services and more components coming into Dapper, I expect also more reduction even on real projects. So what went well? Of course, that is the less source code, technically for me and for my team, that means less technical depth or at least less source code to maintain. We did achieve accelerated development with a minimal learning curve. So of course, the dev developers, they have to understand what is going on and how we are going to utilize Dapper and the whole logic. But once they get that, then it's easy to continue. I'm really happy with Dapper because it's a set of the best engineering patterns and practices. Just the sidecar pattern is also something that is very well established into our world. Simple and elegant secret implementation, leveraging technology-specific features like the Cosmos DB partition key and also the key prefix there. And what I also like is that the abstraction is on the source code level, but not on the architectural level. What I mean by this is that if you decide to use, for instance, like in our case, Cosmos DB, you still have to be familiar and to know how to use Cosmos DB and to know how to design a database in Cosmos DB, but you don't have to write the source code. So you get less source code, but you still have to be aware on how to use the technology that you are going to select. And that is expected, but still I really like how it's implemented. What's next? As I mentioned, first of all, we will explore more non-functional requirements like the resilience, observability, and security before we decide to move to production with the Dapper version of the project. There are new components coming to the ecosystem like the OpenAI component that we would like to utilize and also benefit from that. I'm curious to combine Dapper with Radius and Aspire, and there is also already a session on this conference about Radius and Dapper, and I'm really happy with that. And of course, I would like to explore the cloud deployment options. One thing that we did, we tried to use Azure Container Services and we noticed that there is a difference in the component format, so we would like to see how that will go. If you have questions, feel free to reach out to me, either through LinkedIn or through the email. The source code is on my GitHub link. Feel free to reach out, as I said. Thank you very much.


Yes, we were able to put the ball down when we needed to tell you the truth, Joe, I got to give Messiah all the credit in the world. I mean, defensively, they were amazing and they were relentless and they played, I felt like Messiah really, really played well and thankfully we were able to match that intensity and make big plays at the end of the sets and Shannon did make big plays at the end of the sets, whether it was blocking, whether it was putting the ball down and big momentum swings and Julia is continuing to play well. She's very solid, seldom makes mistakes and is able to put the ball down.  We're used to the background, so we are able to pass. We just feel very comfortable at home. All the things that come with being a home team, I think that came into play. I think the crowd helps when we have them, you know, when we're picking up momentum and we keep making good plays. But in the end, we have to do it ourselves. And I just think it's just an advantage to play at home. Widener was not playing well at the beginning of the season and convincing our team that Widener who just beat Messiah is wider than third because they're actually tied with Messiah. But Widener has the head to head advantage against Messiah. Convincing them that Messiah, I mean, Widener is a really good team. You know, they took Eastern five just like we did. That is going to be a dogfight. And Donovan's done a really good job with that team. And so we're looking forward to that, but have a lot of respect for Widener and what he's been able to do this year.


Highlights the B and N dual-dope carbon layer that encapsulated on MO2C nanocrystals MO2C at B and C were fabricated for accelerating her under alkaline condition. Theoretical calculations reveal that the H2O could be decomposed spontaneously over the introduced B sites and the defective C atoms in the dual-dope carbon layer provide the best H binding sites. The optimized dual-doped MO2C catalyst with synergistic effect of non-metal sites delivers superior her performances. This article was authored by Min Zhou, Shaoli Zhang, Wei Jikong, and others.


Hey everyone, welcome back to theCUBE. The leader in live tech coverage, live at VMware Explorer. This is our second day of coverage, but you know that because you've been watching. You know we have two sets, Lisa Martin here with John Furrier, Dave Vellante, Rob Stretzky on the other set of their live at the same time. We have a great segment coming up next. We're going to be talking about data protection, security, ransomware, all that interesting stuff. One of our alumni is back, Mike Kale, the CTO of Primary IO and Lorenzo Sali, founder and CEO of Primary IO. Guys, welcome to theCUBE. Thanks for having us and having us back. All right. Our pleasure.  Very excited to be here. Thank you so much. Thank you. Talk a little bit about Primary IO, mission, vision, what gaps in the market did you see in from a data protection disaster recovery perspective that led you, inspired you to start the company? Certainly. So we initially started as a migration platform for VMware workload. So knowing that close to 80, 85% of all enterprises are virtualized and are using vSphere is a size VMware platform for virtualization. So we focused on that segment initially. And kind of the secret sauce was we worked very early on with VMware vSphere APIs for IO filtering via product initially. And since we're sitting in the IO path, our algorithms were able to capture only the hot data set. So in other words, we were able to move VMs or applications to the cloud at a fraction of the time like any other product. And from a migration technology, we started looking into disaster recovery, disaster recovery as a service. And as you know, recent activities in the ransomware space. So we saw a gap for a product that could deliver a continuous data production in the disaster recovery space. What's been said with the feedback from customers? As ransomware is a household word, we talk about this done all the time. It's, I'm pretty sure my mommy has even heard of it. But it's also, nobody wants to become the next headline. Right, and that's a huge risk customer churn, brand reputation. Talk a little bit about how the ransomware landscape has evolved, especially the last few years as we've seen some big breaches. Indeed, so a few years back, disaster recovery was something nice to have. And with AI and technology growth and especially the cloud users, the cloud consumption, obviously the bad guys probably start thinking about it the same way. So it ends in the last 36 months plus that the market has been enormously into towards disaster recovery and ransomware adds to that actually. Guys, on the product and technology side and also the business model, we're here at VMware Explorer, what's the relationship with the VMware ecosystem? Okay, and as multi cloud or super clouds we see coming, the operating model with cloud crossing environments is an opportunity for exploits. And the surface area is now larger, obviously, and cloud native. How does that influence your product as customers start to architect the multi cloud, super cloud environment? They have to start getting, they got to start thinking like a systems concept, systems thinking, not just, I got to pull some security on. How do you guys look at the multi cloud? And that's really AI as a gift, so I'm serving the AI in there, but as they start, as enterprises start designing in their strategy to implement this environment, how do you guys vector into that? What's the pitch? What's the story? And how do they engage?  And you have to have a comprehensive data protection strategy, which is why we were one of our product, Protect.io, which is our disaster recovery as a service platform, not a product, was one of the top five announcements here from IBM. So we have a good, deep partnership with IBM. With respect to multi cloud, I think you have- Before we go into multi cloud, explain the relationship with IBM real quick. I'll let Lorenzo give the business context. Okay, we'll come back to that. And then I'll talk about technology. Stay with the tech for now. Okay, go ahead, continue on multi cloud. So we'll come back to the- Multi cloud, because VMware workloads in this whole super cloud architecture that they've been talking about, and kids been talking about it for at least a year, I believe, because we're embedded into VMware with the VAO framework, because we've taken the initial VAO filter that the migration product used, moved that into a replication filter. So we're doing continuous data replication of changed blocks versus backup or snapshot. So you, and we're replicating that into cloud object storage. So you think about the cloud object storage can sit anywhere, and you can attach that cross cloud. So then you have a data fabric and a protection fabric across your application workloads, wherever there exists. And then you can recover back into them, because we're- Got everything. And we orchestrate with vCenter APIs. So we're, you know, the rehydration instantiation of VMs on demand, the cloud provider doesn't really matter because we're abstracted away into the VMware environment. So that's basically an air gap for you guys and they use a bad analogy, but vCenter's what, the console, right, for that? Yeah, vCenter's the command and control aspect. So you guys are basically taking the data, putting it in the cloud, if they get ransomware to attack, you just recover and say, I'm not paying Bitcoin, we just come back and bring the data back. So you recover and we have the ability to recover up until a given point in time, because we keep the metadata of the blocks. And because you don't want to replicate, ideally you don't, basically, when you were infected with ransomware, and you want to recover up to a point before that. And we want to do it into an isolated environment to make sure so you don't proliferate ransomware into your cloud DR. So we've, we're integrating, and we'll announce this more formally later, probably in Barcelona, but integrating into IBM's cyber resiliency platform. So we're the data protector and provider into that. And then we'll orchestrate the failback once the security team makes sure the environment's clean. So the only way for the ransomware bad guys to get the stuff is to hit the cloud too? Correct, and they have to breach us. Which is almost impossible. And they have to breach the cloud provider too, because. Okay, Lorenzo, IBM, we met, saw you guys the first night we hear in the hallways of the event. I noticed you were with a lot of, can big contingent of IBM, I saw some old friends there, multiple entrepreneurs, big crowd, big relationship with IBM. Can you explain your relationship with IBM and how that fits into VMware Explorer, VMware and disaster recovery and ransomware? Certainly, so it's probably well known that IBM is the largest VMware operator, or VM, a number of VMs in the world. So our product being based on Viya platform, VMware, vSphere, then obviously it was a very natural path to make sure that the cloud that we pick, and that our disaster recovery and migration is working on is someone with largest number of VMs and happened to be IBM cloud. And now, not to drop names, in 2018, at the VM world, at the time it was called VM world in Barcelona, I run into Mr. Arvind Krishna. At the time he was a GM of the five VM cloud. So I had seven minutes to pitch. Nice. So we pitched the product and it was based on the hot data sets, the migration and hot data sets. And he loved the idea. We were introduced to the CTO at the time. And then from there, it was just a fast track as a technology partner. So therefore in the last three, four years, we've done quite a few migration projects for IBM and that partnership became deeper and deeper and it's an excellent partnership because a lot of poll we get introduced to a lot of customers. And we are a product company, a tech company. However, over time throughout COVID, there was a lot of demand for some services. And I think if you guys remember GTS, now Kinjal, I was in a spinoff. So there was some request and requirements for services as well. So over time we actually build our own services team that is being led by our field CTO out of London today. So now we've got a migration as a service and then naturally we talk about the disaster recovery as a service. So unlike other tools in the marketplace, we're just not a license that somebody has to go ahead and a customer has to do with themselves or they probably would have to find a professional services to do it. It's all in-house from discovery to migration to disaster recovery managed service. As a service, no product to install. You guys are running the service for the customer. Subscription based? Correct. Okay. It's software as a service. Software as a service, perfect. So it's easy to consume. What's the profile? I'm imagining probably of a range of high enterprises to small, medium sized, large businesses which are hit a lot by ransomware. What's the profile of your customer? Everybody? Almost, yeah. SaaS in a software as a service product. And this is the first authentic SaaS product on IBM Cloud, by the way. For VMware workloads. For VMware workloads. Exactly. So we're focused on those. So people who have VMware are mostly all their customers. Pretty much it's your profile. So, believe it or not, and these are all life opportunities that we have delivered in the last 18 months. We have seen as little as 50 VMs, as many as 2,500 VMs, 3,000 VMs customers. So, to answer your question, yeah. SMB, SMEs, as well as Enterprise. What's the IBM's interest? Because they have customers with a lot of VMware, right? Is that why? They like that? We believe that roughly there is about 900,000 or a million VMware VMs being managed by IBM Cloud today. Yeah, IBM has a good present. And IBM Cloud, because they offer bare metal servers in VPC, is a technology differentiator for the other clouds. Like, because now your workloads operate the same as they do on-prem, but you just don't have to manage the metal, which customers that resonate with. And because when we do failover, it's on demand, your total cost of ownership of our platform is much lower. Because you don't have to have the product running, because we're running the SaaS central console for the UI and we manage the data plane as well and the infrastructure creation and tear down. Mike, talk a little bit about disaster recovery as a service. Obviously, every industry is fair target for ransomware. It's a matter of when it's going to happen to us, not if at this point. But are you seeing any industries in particular being early adopters of the bandwagon of true disaster recovery as a service? I think the profiles and customers we've spoken to and are working with runs the gamut from education to SMB, to large enterprise, Fortune 100, Fortune 20 customers. Because it's top of mind for everybody. Like every day there's a bad ransomware headline, like our Field CTO found one today. I think it was in the UK where, it was a Danish company, Cloud Nordic, they were completely wiped out. They can't recover, they're not paying the ransom.  And then think about financial sector, critical infrastructure, ransomware gets through that. Like we have a big problem as a country. Yeah, and ransomware is brutal, I mean it's devastating. And they don't discriminate, I mean they're looking for it open. The impact is, I mean, if an infrastructure out of the data center is down for a week or longer, that you can imagine what the financial impact on that. Catastrophic. As I mentioned earlier, it's not a nice to have anymore. It's a must have. My last question before we wrap up is, what is the current state of the art for you guys? What do you do next? What's on the horizon? So obviously, focusing on the product, especially the combination of disaster recovery as a service and an extension of that being ransomware recovery. With the size of our company, we are laser focused on IBM Cloud customers and their requirements. So we talk to the customers very closely. And there is a list of additional roadmap items that we're focused on for the next 12 to 18 months to bring on board and working very closely with the customers from IBM Cloud. And the beauty is that the customer success management, tech sales and IBM and Cloud sellers were connected to all of those three organizations to take it in front of the customers. Let's make some good bank with IBM. What's the product focus? I think one of the most interesting potential features we're thinking about or I'm thinking about is because we sit in the data path, looking for anomalies, whether data is being encrypted all of a sudden, there's different signatures, which means there's probably been an event and then you can at least stop, try to block and then recover faster with a greater assurance of when you were infected to get back up and running without paying a ransom or paying cyber insurance, which probably won't cover it anyway. And then having to tell your customers you lost the data. So being more predictive I think is a good next AI hashtag, hashtag AI feature. Right. Last question, Mike, take us out with, if you have a favorite ransomware recovery story that you can share, don't have to name the customer where primary IO was the primary reason that they were able to return to business as usual? I think the main one was a customer was hit. They had no idea when it happened and they were trying to restore from backup tapes. And that's a slow process in general. And then if you keep going and going and going, so they're a good reference customer to like, we need your solution because we can't go through this again. And we're not sure we won't have to go through it again. So now how do we have proper protection? They had no idea where that mark was. No, no. So they were blind. Yeah, yeah. So they spent, it was weeks, maybe months of trying to get back. Just to add to that, he asked about verticals. Honestly, so almost every vertical is affected by this and that the customer that Mike was referring to, it was a large retail chain. So anywhere from retail to financials to medical billing systems, these are the two, three customers that we've worked very closely with that, you know, complete different verticals. Right, education as well. Yeah, yeah. Education space, exactly. Yeah. Taxation, by the way, the tax company here in the U.S. that benefit from it. So all verticals, excellent guys. So primary IO.com is the website. Go there, check it out, check out this technology, how it can help you really implement true disaster recovery as a service. Guys, Lorenzo, Mike, great to have you on the program. Thank you so much for joining us, spending some time and sharing what primary IO was really enabling organizations to achieve. We appreciate it. And thank you. Thank you so much. Thank you so much. Thanks, thanks. All right, our gas sensor, John Ferrier. I'm Lisa Martin. You're watching theCUBE live from VMware Explore Day two. Stick around, our coverage continues next.


Under the course Trends and Issues in Early Childhood Education, now we will see the Biological System Theory of Human Development. Bronfen Brenner in 1979 organized context of human development into a set of five inter-related levels called the Bioecological System Theory of Human Development. Bronfen Brenner gave us the theory of five integrated systems in which the child learns. The first one is the Microsystem, which is the circle of your family and your home. The first one is the Microsystem, which teaches behaviors and attitudes, languages and manners. Then is the Mesosystem. If you go out from your family, the environment of the heart is in the Mesosystem. If you are in a neighborhood, a park, and then in the long term, you will go to school or become a part of an ECC program, then there will be more interaction with some people. This is your Mesosystem. There are stages of sociability, as I am saying. The first one was the home. It was a stage. Your relationship can be from 8 to 12 or all the individuals. If you go out, it can be up to 50 to 100 individuals. This is your Mesosystem. Then the Exosystem. This is your community. Sometimes you are going on a celebration, somewhere to travel, or if you are a community function that you are a part of, then there is more interaction. You deal with more people and learn to deal with them. Then is the Microsystem. The Microsystem is the whole world. Hold the universe, your universe. Where do you live? Which country do you live in? What is your identity in the whole world? What is the global community? What are the human rights of the people? The next one is the Chrono System. The Chrono System actually works within all these previous systems. This is your age. Along with time, along with age, in your sociability and in your social skills, it keeps increasing. That is, if you have come from your family, from school, from school, from community, from community to the whole world, then it takes time too. So as your age increases, similarly, in your sociability, in your understanding, in dealing with people, there is a difference. So each level of Bronfenbrenners' bio-ecological system theory of human development is connected to the others. Now these are not isolated systems. Each system gives birth to others. The next system that I have learned, the Mohartas, it works in that system. And then they are interrelated. They come back from there. For example, it is not that I have taught my family's system. After that, our child went out. He has learned some more things in the school system. So now the things that are learned from the school cannot be taught at home. Those who have taken culture from outside, those who have learned manners from outside, they will also come back to the family. Exactly the same way what he has learned from the global community will also bring it to his contextual internal community. So all these systems are interrelated. And what does this do? They act in both ways in the future.  And in a bigger system, you bring things back to your smaller system as well. So now we have seen that in this way, sometimes there are disturbances.  You have to speak well. You have to help others. You don't have to harm anyone.  You don't have to steal anything from anyone. You don't have to steal anything. But when that child goes out and sees all these fights, fights and abuses, he will come back and disturb your circle. So that is why we understand that to create a good leader we have to keep all the systems in mind. And we have to create coherence between them. Whatever they have learned at home, they should go out and act. And what they have learned is to bring back the selected things that are good and bad. So this is the demarcation that we have to make.