Okay, so thanks everybody coming back and that great lectures we're going to have some more right now. And so the first lecture today is given by Professor Randy Babbitt also in Montana State University. He's a professor of physics and director of spectrum lab. And so he's been a he's one of quite a few awards actually has got 81 papers, quite a few 18 patents that's really great. And so you can tell we're talking to technology people, but a rate so he's he's I think you and you and Joe have known each other for quite some time. Oh yeah, we're piecing a pod here. He's a pod. So anyway, we're really really happy to have you come here. This is, by the way, I just want to let you know I've been is john how hooked up here. I don't see him. Well anyway, I was talking to john how today. And he was he was one of our speakers lecturers yesterday. He liked this so much. We're thinking about making a program.  Something something kind of global pay rates. Maybe there's a spin off coming out of this. And for the next year for the day of light celebrations. All right, so anyway, well Randy I'll just let you go ahead and take over here. Let's talk about coherent light are and digital photography or the my schedule. That's the game plan. You let them know whether they can ask questions. They can raise their hand. Okay. No problem. Well, let me share a screen here. Yeah, no problem. Just interrupting and asking questions. And you guys can hear me just fine. Is that correct? Yeah. All right, let me get my sheet screen shared. And which one do I want screen to there we go. All right, you see my full screen. Okay. All right, and then pop that one up here. All right. Okay. Hi, I'm Randy Babbit. And as I said, interrupt me anytime with questions. Abdu will monitor that. Is that right? And just. Or someone will have to keep track. Okay. All right. And so I am a professor of physics been here 25 years and I'm director of spectrum lab, which I'll talk a little bit about at the end as well as a little bit about optic and Montana optics companies. If we have time. And I'm going to talk today about coherent light are and digital holography, which are kind of two distinct things.  So I'm going to talk a little bit about light are direct versus coherent to begin with. And as far as coherent light are I'm going to really concentrate on FMCW frequency modulated continuous wave light are talking about the principles advantages and disadvantages. And chirp generation, which used to be a major problem, but it's now second nature these days. And what it can be used for everything from metrology of small objects to long range light are. And then I'll talk about switch gears and talk about did your holography. I'm going to talk a little bit about image plane, digitalography, pupil playing. When we talk about pupil playing, we need to learn a lot about optical wave propagation. So I'll go into that. How we get image recovery and how you can focus after the fact after the recording, you can change your focus and holography. And the requirements, the signal noise ratios and depth of field you get the digital photography. And then I'll talk about FMCW digital holography, which is something we've developed here at Montana State, which is a way of doing range selective digital photography combining basically FMCW light are with digital holography. So let's think about direct detection light are talk about that. And in general, what you do is you send out a pulse and we'll call it an intensity pulse going out. It's could be just a pulse. It could be a modulated pulse, but some something in time goes out hits a target. And what you get in return is actually a convolution of what you sent out with the target's range profile. So you get quite a convolved return here, a complicated return. But if you send a pulse out, and the target is just some flat surface that is small, respect to the range dimension, then you basically get a pulse back. And so we send out a pulse and we'll say that the pulse is only TP or long. You wait a time tau, which is basically the time it takes for the pulse to get from the transmitter to the target to the receiver.  Your reigns resolution is just the derivative of this. So it's essentially your ability to measure time accurately. And in this case, that's roughly the width of the pulse. We'll talk a little bit about Rayleigh limit here in a second why why why those two are related. And so if you have like a six nanosecond pulse, it might get one meter resolution. You would need a detector that could do greater than 150 megahertz to see that. If you wanted something more in the order of one centimeter resolution, you would need like 60 pika second pulses, or 15 gigahertz detector so pulsed. LiDAR has an issue with range resolution requiring high bandwidths. I just want to say a little bit about what you have a range resolution there. You really is range resolution precision and accuracy and you have to keep those apart. Resolution is really your ability to resolve and it's really related to spectro Rayleigh resolution. It's when two targets can be resolved and aren't on top of each other. And here I'm showing three cases one where two targets are well separated greater than their range resolution twice the range resolution when they're separated by twice the range resolution. And when they just become really just one blob is when they are one range resolution. So here are the separated individual target returns. And then if you combine those we can see that when you get down to the separation being between the two targets being the range resolution you just looks like one blob and then you lose their individual characteristics. So that's your range resolution. And in essence that's the basic the pulse width time C divided by two. Your precision can be much greater though because if you only have one pulse and you want to know how precisely you can identify where that target is. If you've got good SNR you can basically find the center of that blob to basically the range resolution divided by the square root of the signal to noise ratio. So you can zero one on the center. It does assume you only have a single target and you have some good timing resolution. But you can and good signal noise you can get much better precision than you have range resolution. And then accuracy is another thing and that depends a lot on has has many things that it depends on your timing accuracy, your knowledge of the propagation through any of the optics as well as the atmosphere or wherever you've got what you're going through the index refraction. I mean the difference between assuming air is one and the air is one point zero zero zero three or zero zero zero six depending on where you are what your temperature wavelength pressure and humidity are. You can get considerable errors. If you were a kilometer out this is on the order of point three meter air. If you assume the wrong index. So now let's talk a little bit about direct versus coherent detection. Here is a light field with an amplitude. It's light food returning from a target. So you have a amplitude that's delayed by the round trip to the target. It's on a cosine background sinusoidal background also delayed with respect to the target. And the assumption here is that that we can detect the intensity of this pulse. So you have a the bandwidth of your modulation. This pulse is less than the bandwidth of your detector, which is much less than the wavelength of light or the frequency of light. And so you can't detect the frequency of the light, but you can look at the intensity of this. And so in direct detection, that's what you do. A detector is really a square law detector and what that does is it squares your optical field and then averages over the integration time of the detector, which is roughly one of the bandwidth of the detector. And so if you take this and you square it and then average it.  The averaging gets rid of that twice optical frequency. And all you see is the envelope squared when you do direct detection. When you're doing coherent detection, you will mix the optical field with a local oscillator. So we'll take the delayed return signal and mix it with a local oscillator, which you define as a cosine. But typically we do this at a different frequency. It's heterodyne detection rather than the home of dying detection. So we mix the return signal, which is at frequency of the laser with a different transmit laser with a different laser that is slightly shifted. And we look at the intensity of the combined signal. If you look at the intensity of the combined signal, you have the intensity of the pulse that comes back. You have the intensity of the local oscillator, which is flat and amplitude.  So you get a signal back with a bead on it that has an envelope that was the envelope of the return pulse.  And you basically have a nice DC offset. You have an amplification here of the return signal. Up here you had AR squared. Here you have ALOAR. So you really get an amplification of the ratio of the amplitude of the LO signal divided by the amplitude of the return signal. It's on an optical carrier, which is nice because it's removed from DC, makes it a little easier to detect. You can adjust this frequency so it matches whatever detector you're using. And there's a phase term here, which usually we ignore, but it's actually interesting because one, if there's actually added phase that can destroy your signal, but you can actually use this to do things like frequency shift at holography or study vibrations or dobler movement of a target. So this phase term can come in useful in many cases. So pictorially, here we have that this direct detection, you basically just have a blob coming back with the envelope squared of your return pulse. And the coherent detection, you still have the envelope, but it's modulating a cosine and riding on a DC background. So this is just a pictorial way of looking at what we were just showing before. So the one issue with that phase term is that if something is moving, if your target's moving on the order of lambda, that can switch that cosine from, if you go lambda over four, switch the cosine from a sine to a cosine, which can be a problem because vibrations or movement can really distort your signal or diminish your return if you integrate it. But like I said, the nice thing about that is that that phase term can also give you dobler measurements while symmetry. If the movements are small, you can actually study the vibrations of a target through that phase term, but I'm not going to get too much into that. I just wanted to mention that. So the signal to noise considerations, if you have direct detection, then your signal to noise is basically governed by the power of the return, the duration of the pulse that comes back, your quantum efficiency, plane's constant, and the frequency of the light. And the noise is usually the simplest way to look at it. It's the shot noise, the square root of the return photons, plus thermal noise that's in band. And so your signal to noise would be the ratio of the number of photons that get back, the square root of the number of photons, plus photons in the photo electrons, this is actually in photo electrons, and the thermal noise. In order to get to the shot noise limited, you need to have your number of photons in your signal much greater, the square root of that much greater than the thermal noise. So you have to have very strong signals to get back in order to be shot noise limited. When you're doing coherent detection, your signal is the square root of the number of LO photons times the number of return photons. Your noise is the square root of the local oscillator, which dominates. It's actually the square root of the local oscillator plus phi r, but we usually ignore that part. Plus the thermal noise, if you look at your signal to noise, rather than the number of photo electrons in the return, it's the square root of the number of photons in return times the square root of LO. The interesting thing about this is if you have a really strong LO, then these two terms cancel out. This is much greater than this. You can actually get to a shot noise limited detection, square root of the number of photon electrons in the return, and you can do that in a case where the number of photo electrons is much less than the thermal photo electrons. So you can actually get single photon detection even when you have thermal noise. So that's one nice thing about coherent detection is that you get that amplification to the point where you can actually get shot noise limited signal detection. Let's talk about what it takes to get good resolution with the pulse lidar. Like we said, the range resolution is a function of the duration of the pulse, which is also inversely related to the bandwidth of the pulse or the bandwidth of the tector you need to measure the pulse. So one way to increase your resolution is to increase the bandwidth or shorten your pulse. If you don't increase your power, that's less energy. So usually in order to keep your signal noise the same, you have to have intense brief pulses. That can get expensive and technically difficult. Brief optical pulses can cause optical damage. They can be less eye safe. They require high bandwidth detectors to see them. And there can be distortions and jitter in the creation of those pulses. So that's why we go to FMCW because it doesn't require shorting the pulse. It's a way of increasing bandwidth without shorting the pulses. So FMCW is based on chirps, chirped pulses. What's a chirped pulse? Actually, I think Joe should do this. He did a really good sound of chirps the other day. But I'll try it. A chirp is... Listen to Joe's but he's better recording. So what is a chirped pulse? A chirped pulse is a pulse that starts at one frequency and ends up at a different frequency and literally ramps from that starting frequency to the end frequency over a certain bandwidth of the chirp. And it does let over a duration, tau C, and you'll see these bandwidth duration of chirp a lot of times. So remember those. At a chirp rate, which is the ratio of the bandwidth to the duration. And you'll see that a lot too. And mathematically, you can write that as here where we see there's this one half cap of tau squared because the frequency is the derivative of this phase term. And so if you look at the frequency, the frequency would be F naught. The derivative of this would be F naught plus cap of T. And this is the phase here of the linear chirp. All right. So let's look at what FMCW LiDAR, how it uses that. If you send out a transmit pulse that mathematically looks like this, which is... I've converted to angular units here. So you have the frequency of the laser times time, and one half times the chirp rate converted with two pi, tau T squared. The received pulse comes back tau later. So it's the same equation. We're just with T minus tau's in it. And then when you do the coherent detection, you beat those two together, and it's really just a subtraction of these two phase terms is what you end up with. And if you look at what's left over when you beat those two together and get rid of the high-frequency terms, you spatially filter it or look at the intensity averaged a little bit, there'll be a term, there'll be a phase term that's a function of the frequency of light. But there's this term here, which is very interesting. You just cancel and you get alpha T tau, or in terms of kappa's, kappa tau, which is a beat frequency. And that beat frequency, kappa tau, tau was related to the range. So you have this beat that is proportional to the range. So if you measure this beat frequency of the coherent detection, you basically divide it by kappa and multiply it times c and divide it by two, you will get the range. So that's how you basically convert FMCW signals. You take a, let's switch over here. You take a 4A transform of the beat signal. Well, let me talk about this a little bit. Let me talk about the experiment first or the typical setup is a chirped laser. You split that into a transmit and an LO. You send the transmit out through a circulator. A circulator is nice because the transmitter pulse goes out and the return pulse comes back on a different path. So the pulse, transmit pulse goes out and comes back and beats with the LO. And then you digitize that. And I'll talk a little bit about the requirements on the digitizer and the detector. And then you 4A transform. So you send out a chirp. It comes back as a delayed chirp. And so a delay in time here causes a frequency change between those two, between the laser and the transmitter pulse and the return pulse. This is the beat frequency capitao. And because it's a linear chirp that frequency beat is constant. So you get a constant tone during the whole pulse. And if you take a 4A transform of that, you'll get a beat frequency that can be multiplied and converted to a range. And so here's your fast 4A transform, converted units to range. And you get a very nice, sharp pulse with a range resolution that is C over 2 times the bandwidth, which is the same range resolution we had with pulsed LiDAR. C over 2 times the bandwidth of the brief pulse. But now we have a pulse that's much longer than what it would take, much longer than a brief pulse. The range resolution all comes from the bandwidth, not the duration. The duration of the pulse actually, the duration of the pulse, let's see here, the duration of the pulse comes in in terms of kappa here and your ability to measure that frequency well. All right, so what are the disadvantages of FMCW LiDAR? So now we've got this range resolution that's a function of your chirp. But now you can have durations that are much longer than one over the bandwidth. You can have like a multi gigahertz chirp over a millisecond time scale. So you can have a factor of 1,000. The duration can be on the order of a million times one over the bandwidth. That's typical. We can do anything from 1,000 to a million times. What that allows you to do is to put a lot more energy on the target without having much peak power. The peak power can be really weak. You have a long pulse, get a lot of energy on the pulse. And so that higher energy gets you better SNR. There's less chance of optical damage because you're relatively weak pulses. I mean, you can have a watt signal, but if you take a watt signal, but you can have it on for a long time. It's more eye safe going to long pulses rather than brief pulses. The detector requirement, the bandwidth requirement, is no longer the bandwidth of the chirp or the pulse. It's the bandwidth that allows you to get to measure the beat frequency. So you can have much lower bandwidths. You can get high resolution with tens, you can get the equivalent of gigahertz resolution with the order of megahertz detectors. And likewise, you're digitized on the same range on the megahertz. And because they're pretty well characterized, and I'll talk about that in a little bit, you have much less distortion or jitter. The disadvantage, well, they're a little more expensive and technically difficult to produce, but they're becoming ubiquitous. The amount of volume of FMCW sources is getting large. And there are new techniques to doing this. I'll talk about one technique, but they're more advanced techniques for producing FMCW laser sources. And so the cost is coming down and the performance is getting better. So when I first got to Montana State, I did nothing about LiDAR or anything like that. I was working on something called spectral holograms rather than spatial holography. And it's really a form of spectroscopy. We wanted to read out a material very quickly. I wanted a chirp pulse that could do 10 gigahertz and a millisecond. And it took 10 years to develop that readout capability. So I'm not going to go into this. I'm just saying that this is sort of the history. And one of the issues we ran into is chirp nonlinearity. I was working with chirp pulses in the 80s and you basically would ramp the current of your diode or change of grading. The problem is it wasn't linear. And so if the chirp isn't linear, so it's doing some path and you send that out and then you get delayed return, the beat frequency varies.  And what that does is it greatly broadens your peaks and reduces the height. So your signal is spread out and therefore your range resolution is essentially destroyed. You can have a gigahertz chirp with meter type resolution, but because of the noise on it, you almost have kilometer errors. It's not good. And so my, actually, Tom Mossberg was my advisor when I was a graduate student. His team came up with this idea of how to stabilize the chirp.  And as long as it doesn't actually have to be stable long, but it has to be stable during the duration of the chirp, you take this beat frequency and you compare it to some reference beat frequency and you feed that back so that the laser constantly keeps this beat frequency here the same as your reference frequency. So there's a feedback system and that will linearize your chirp. We took that technique and advanced it to the point where we took a picadilaser, which can do terahertz. And so we were doing terahertz scans over milliseconds. So this is actually some work done by Pete Roos and Randy Riebel. Randy was one of my students and Pete and Randy were working in Spectrum Lab. Pete's also a graduate, a Ph.D. graduate of MSU. So it was a trend. It was a MSU graduate. Zeb was a MSU undergraduate under CU. So all these people are MSU people, graduates. They came to me and said we can not just do 10 gigahertz over a millisecond, but we can do terahertz and we can do it with sub-100 kilohertz linearization. And so they came up with a technique for doing that. That was a good thing. The kind of good and bad thing was they said, well, we could care less about spectra holography. We're going off and doing LiDAR work. And so Randy and Pete formed Bridger Photonics, which then split off to became Blackmore Sensors, which then became Aurora. So major economic development came out of this in the Bozeman Valley. And so here's a little bit of what that technique looked like. What the results are is that if you have a, take the Pika-D laser and just sweep it, and it's a grading-based laser. So it's really just sweeping and grading. And you look at the linearity errors, they are on the order of half a gigahertz. So if you just chirp the laser, you'll get half gigahertz errors as you chirp in time when it's unlocked. But if you lock it, that little noise right down there, and here's a blow-up of that, you can get that noise down to on the order of 100 kilohertz or better. And so what that looks like in range, relative range resolution is rather than having, when you're unlocked on the order of meter-type resolutions and noisy, you get this nice spike with the order of 50 micron resolutions, equivalent of 50 micron resolutions. So here's an example of that 50 micron resolution on the order of a meter timescale, meter-meter distance. They were tested that by actually moving a target with a picometer and actually showed they could actually measure 10 micron steps with, on the order of 47 microns resolution, they could actually do it with 86 nanometers of precision, which means that because they knew it was a single target, they could come in and analyze the position of the sound to the sub-micron resolution. They used that for doing some fun things like profiling. They could look at a penny and look at the word liberty on the penny and get profiles of that.  Let's see, what else? The other thing they did is they looked at contact lenses and analyzed the profile of contact lenses that were being made by a Montana company called WaveSource. Oh, and they also formed Bridge over Tonics, which we collaborated with us. They looked at long-range measurements with these LiDAR techniques, and they showed that at a kilometer, they could get 100 micron peaks, 100 micron range resolutions at kilometers, and they actually went to 14 kilometers, and they could actually get sub-millimeter resolution, and that really was more turbulence limited. And so, very precise measurements at long-distance, precise and high-resolution measurements at long distances. Another nice thing about FMCW, it's good and bad thing, is that the return is also the shift in the return. The B-frequency is a function of the movement of the target.  And so, you get your delay causes a frequency beat that's a function of range, but then the movement causes a Doppler shift, which also causes a shift in light. So, you get a delay shift, which causes a frequency beat, and then a frequency shift due to the Doppler. And so, that can give you a range Doppler ambiguity. So, you'll hear a lot with FMCW techniques, whether it's radar or LADAR. By the way, FMCW has been in radar for a long time and range Doppler ambiguity has been an issue. You can solve that by doing up and down chirps. And so, here's a case without the Doppler up and down chirp, you get a, here's your transmit, here's your return. The beat is the same when you don't have any movement, but if you have some movement of the target, then the return signal is upshifted. And so, here's your new return signal that's been upshifted in both locations. Well, that upshifting causes a reduction in the beat on the upside and an increase of the beat on the downside. You can use that, those two measurements, to get the range beat, which is the one that's a function of capital, and the speed, which is the Doppler shift. So, you can use the up and the down chirp to remove the range Doppler ambiguity. Blackmore sensors, which spun out of Bridger Photonics and became Aurora, came up with a technique of doing double sideband FMCW. In that case, I don't want to go too far in the technique, but you go into, you have a double sideband, you have two sidebands chirping, which we will get if you electronically chirped an electro-optic modulator, phase modulator.  You add a frequency shift with an acoustic modulator, and you go through all the math, and I'm not going to go through all this, you can look at their patent, but from this one measurement, rather than having to do an up and a down, you get two peaks, and if the target stationary, you get these two peaks, if the Doppler moves, if there's Doppler shift, you see a shift one way, a shift the other, you can analyze those peaks to get the same information in a single measurement. They took that technique and did a lot of interesting things. First, with just regular scanned FMCW of stationary targets, they showed the high precision they could get. But here is the Montana State Stadium. This isn't just a picture. This is a point cloud of a scanned FMCW system where they've measured the distance to every point here and plotted it. And the nice thing about these, I don't have any movies of this in particular, but you can rotate this and look at it in 3D. Likewise here, you can rotate this and look at it in 3D. One reason you can see that this is 3D, the shadows you see here are not the shadows of the sun, but the shadows of the lidar. So this lidar was sitting over here and going this way, the lidar was really over this way, but then they were able to turn the image after the fact, the point cloud and look at it from a different angle. So that's one nice thing about the point clouds that you can make with FMCW is you can turn it all around. You get a great 3D. Here's another thing they were doing. So they took this and they showed that they could do the range and velocity. And Blackmore became a roar, which is very much into automotive lidar, which Joe was talking about the other day. And this is an interesting thing where you can see the cars going by. You can see people walking by. And what you'll see is that sometimes the people turn blue or red, that's the question of whether they're going towards you or away from you. And you actually see the velocities. Here's the lidar here. This is blue coming towards the line of sight and red as you go away from it. So it's going away as red, blue coming towards you. Things that are moving across range stay white. And so you can get the range Doppler velocity. And so this is the basis of a lot of their work on automotive lidar. And how do I get beyond that? There we go. All right, now let's totally shift gears to digitalography. But are there any questions about the FMCW at this point? No, Randall. Thank you. For now, there is no question. OK. So let's totally shift gears to digitalography. And let's cover all of digitalography in about 15 minutes. OK. So in digitalography, you also send out a field to hit a target. And that hits an object. And the light field comes in and hits the camera. And so at the same time that a reference beam. So we have a reference beam, which we can describe as an E field, a constant E field times a cosine plane wave. The object beam is a much more complicated. It's some optical field. We don't actually know its direction. It's just some complicated phase at the camera with some complicated amplitude. And this is the thing we're trying to measure. What is the amplitude xy and the phase xy of this field that is scattered from this object? And we do that by interfering that object field with the reference field. We beat those together. We capture the intensity. And again, the intensity is the time averaged square of the sum of the object and the reference. And if you look at the cross terms or the cross terms on that, you actually have a multiplication of the object field with the reference field. You have some DC terms here, which we typically ignore because we can actually filter out these DC terms due to this modulation. The electric field of the object and electric field of reference are actually riding on a modulated background. And by doing Fourier transform on that, we can actually filter out the other terms, filter out this term, only pick out the terms of interest. This term is actually a constant. It's the constant reference, so we can actually pick out this. And I'll talk a little bit more about that. I just want to say, whenever I say camera, I really don't mean a camera with a lens. I'm talking about a lensless camera or focal plane array. So when I say camera, it's really just the sensor, not the sensor plus lens. All right, so a plane wave goes along. It's just a simple background. Here's a rendition of a plane wave. When two plane waves meet, they basically, you can see patterns here of high and low. Those are high intensity regions that form gradings with a periodicity that's actually a function of the angle at which the two meet and the wavelength of the light. When the reference beam and the object beam meet, they form thousands of gradings on the camera. And so there are two ways at which we can do the beating on the camera. We can either do it with no lens in the system, and that's called lensless holography and also pupil plane, which means that really you're so far away from the target that you're really in the Fraunhofer limit here and you're looking at the pupil plane, or you can actually put a lens in and image the target onto the camera and do image plane. I'm going to talk about image plane first, and then I'll talk more about pupil plane. So an image plane, you've taken the target and you've imaged it onto the camera. You formed a interference pattern that has an interference of the object with the reference, its complex conjugate, and then some DC terms. If you take that combination on the camera and you fast forward a transform it spatially, two-dimensional, fast forward a spatial transform, what you'll see is that because of this K dot R term, this term shows up here, this term shows up there, and the DC term show up in the center of your, in the Fourier domain.  And the nice thing is you've actually got the target, not in intensity of the target, but you have the full phase information about the complex phase information about the target at that point. The setup looks a little bit different than what I just showed you. You take a laser, you want to polarize the light because when they meet here, you want them to meet with the same polarization. You form a reference beam and you want it nicely spatial filtered on the image, the better spatial filtering you get and the more uniform it is, the better the reconstruction.  And then you record that and then you do a lot of post-processing on that. That's basically the same thing I showed a second ago. When you're doing, oh no, this, oh, let's talk about, that's not image plane, this is pupil plane, I'm sorry, lensless pupil plane recording. So change that word to pupil. So in pupil plane, we had just talked about image plane, in pupil plane there is no lens. What you see here is it's a blur of the target hitting here, beat with a reference signal. So you take that blur of the target, beat it with a reference signal and then what you do is you add in a phase factor which we'll talk about in a second that focuses the beam when you do a 4A transform and actually produces the target and then you can mask out that and you'll get the real and image part. So understand this, we need to know more about how optical field propagation works and what I'm going to talk about very briefly is how to get from your object plane here, which we'll call U1, to the camera plane, which we'll call U2. And that's based on Huygens principle that at every point becomes a spherical wave and so a plane wave is really just a bunch of spherical waves that reproduce a wave front. Spherical waves work the same way. If you take Huygens principle and you say that every point on the object becomes a spherical wave and we tend to ignore the cosine term, which is inclination factor, which is hard to explain, but we usually just set it to one and you take this integral to get to what gets produced at the new point U2, then you get this equation here. If you make some assumptions, which are the Fresnel approximations, you assume that the range is far. If you assume the range is far, then we can make some assumptions about K times R. We assume the cosines one and what we get is the Fresnel diffraction integral and so you have the field at U1 is multiplied times this term here and this term here and you get the field at U2. You can continue to make some assumptions about that. If you break this up and turn it into your x, y coordinates and then you make some further assumptions, Audrey is going to go quickly here because I'm running out of time, what you find is that in the Fresnel propagation you have the field of the object, you have a phase term, a quadratic phase term multiplying the field of the object and then you have this, which looks a lot like a Fourier transform. You have the integral of dx of something that's a function of, sorry, dx1 and y1, something that's a function of x1 and y1 times an e to the ik and you can think of this thing as the spatial frequency, ikx2 over del dz is sort of a spatial frequency. You're really doing a fast Fourier transform here and then there's some quadratic phase terms on the back end that you have to take care of as well and so the result is really a Fourier transform of the field with some phase terms added in and what makes that interesting for when you're doing fast Fourier transforms, when you're doing, I'm not going to be front of her, when you're doing pupil plane and you get this return signal and you capture it with pupil plane holography, you basically can get the electric field, you can undo that. So here's the field that you would get for Fresnel propagation. You record that in the intensity of your hologram and you basically pull out the e object by doing the Fourier transform, but before you do that, what you do is you multiply the intensity by this opposite of the scale factor, which is really a focusing factor. You undo the focusing effect and you can pull out the image. Now the interesting thing is is that that range was arranged with a target and what you do is you can pick out that this thing picks out that range and so you can, if there were two targets at different ranges, you can set your range here to whichever target range you want and focus that image. So you can actually focus different objects this way, but depending on what you put up front here when you do the Fourier transform. Let's see, I'm not going to go there and so this shows you how, let's see, this over here. This one shows you how if you change this focus factor here, you can actually bring targets into focus, 20 centimeters, or out of focus from 12 centimeters, gets pretty blurry, up to 30 centimeters is blurry, you can change the focus of what you're focusing. If there was a target at 30 centimeters somewhere else, it would have showed up in focus. All right, digital photography requirements, a stable laser, spatial stability targets moving, that'll wipe out your gradings. You need some post-processing. If you want to do it real time, you better have fast CPU or FPGA or GPU on the back end. You need a good local oscillator and the camera requirements are something I'm going to talk about very briefly. The pixel size and the number of pixels, talk about that here. If you look at your object and you think about the fact that it has a resolution on your object, delta 1 and a size D1 and your camera has a size D2 and a resolution delta 2, then the two things are related. The resolution here dictates the size of the camera you need. The resolution here is a function that you need over here is a function of your range as well as the size over here.  If you have an object that is size D1 at a range r and using a wavelength lambda, then your pixel size better be lambda r over D1. The total camera size is a function of how big the resolution of the targets you want to achieve. If your target had resolution delta 1 that you're trying to achieve on the target, then you need a camera that is lambda r over delta 1. So the higher resolution requires a bigger camera. Bigger objects require finer resolution of your pixels. That's in addition to a requirement of the angle of your object beam to your transmit beam, which can be a maximum of lambda over two times your pixel resolution. So your pixel resolution, remember that if the bigger the angle between your transmit and your reference and your object creates a higher resolution rating, you better have a higher resolution pixels to grab that. This just says that essentially the signal-to-noise when you're doing digital photography, if you have a strong LO then the signal-to-noise the noise on the LO, the number on the LO cancel and you basically can get shot noise limited detection in digital photography just like you can do in coherent detection with FMCW. Depth of field. The depth of field of holography is really the same as conventional imaging. Where the depth of field if you want to do diffraction limited is a function of the range. The longer the range, the bigger the depth of field. What is the depth of field? It's the range over which the object is in focus. So here's an object in focus. You change the range by three centimeters and it's pretty much still in focus. You continue to change it, it gets more blurred.  They become blurs. If you had two targets there at different ranges, it's hard to distinguish between the two. That's why we combined FMCW with digital photography because we want to get not the depth of field that's of conventional holography, we want the depth of field of FMCW LiDAR. We want to get this high resolution of FMCW LiDAR. One of the stuff we've done recently is to combine digital photography with FMCW techniques, which means that what we did is we took an FMCW beam, we sent it out to our target, it came back delayed. If we just put this on the camera, there would be a beat. The grading would be beating and the camera would integrate that to zero. So what we do is we then take our transmit beam and we offset it so that the beat between the return light and the LO on the camera is zero. So we get a nice stable hologram. Now to do that, that offset is a function of the range of the target. We can pick a range at which we want to look at a target. Here is the setup that we tested this with. Our source is no longer a CW laser. It's a frequency modulated chirp. We send that out through two acoustic modulators, which allows us to adjust the frequency shift between the transmit and reference beam on the camera. We put out two targets.  And I won't go into the details, but one, if we just had the target out there, we really see very little difference between a CW conventional DH and our FMCW DH. But when we have a screen in front of it, here's the conventional digiography. When we use FMCW, we can either focus on the star target, in which case the lens mount is blacked out, or we can use that frequency shift to look at just the scatterer in front, so we can actually have range-selected digiography. And these were about 12 centimeters apart. We have range-selectivity here on the order of two centimeters, which in conventional geography you cannot get. The only interesting thing is that you can see the star in front of your target. And here's a picture of that. Here's the conventional CW DH. And what we see is we can barely see the star pattern here. But with the FMCW digiography, we can actually pick out the star, return from the star, and eliminate the scattering. Just a little bit about Spectrum Lab. We're part of Montana State University, about a million dollars a year. We help develop and help commercialize and grow companies. We're part of the university, so we're not commercial ourselves. We work on both this coherent LiDAR and imaging, on networks, and some of the past work we've done has been on spatial spectral holographic that Montana has on the order of 35 optics companies in Bozeman. I think it's over a thousand employees now. And so we kind of like to think of Bozeman or the Gallatin Valley as the photonic valley in the U.S. We have the most optics companies per capita, but we don't have many people, so when you divide by zero, you get a big number. Any questions? Thank you so much, Randall, for this wonderful and informative talk. So for the participants, anyone who wants to ask a question, please raise your hand. Okay, I think there is one question from Shehzad Ali. Okay, Shehzad Ali, you can unmute and ask your question, please. I'm not hearing anything. Okay, then the next question is from Liru. Liru, you can go ahead. Hello, thank you for your presentation. It's very interesting. And I have some questions. The first one is how could we analyze the noise? I think in the data there are many noises. How could we analyze and analyze the noise accuracy? Thank you. How can you analyze the noise accuracy? Yes. How can you analyze the noise accuracy? How do you measure the accuracy at which the system is working? You have to have another way of calibrating your targets and knowing the range distances between targets, so that's one way to characterize the accuracy. Is that what you're asking? The accuracy of the system? Maybe how can we analyze the height accuracy? Because you see in the LiDAR in one place there are many different point clouds. How can we analyze which point cloud choose the real height? The only way to really do that is to compare multiple point clouds with one another and compare them or use some sort of reference to measure that. I think that's the only way to measure the accuracy at which it's going. The accuracy depends on your chirp rate so you need a very accurate chirp rate and that's usually done by comparing it to a reference or producing it digitally. Thank you for your opinion. You're welcome. Any other questions from the participant? People are waiting to raise their hand. Randy, Tom Moser is your advisor. He's my graduate advisor, yes. No, Shahzad. No, we have another question. Shahzad Ali, you can ask now. My question is what is the distance distribution of random point in our question environment? What is the distribution? I'd say that again, please. Shahzad Ali, can you please repeat your question? What is the distance distribution of random point in our question environment? The transmission is being garbled. Can you say that one more time? The random, I got distribution of something. Shahzad, can you please say it slowly because it's a bit noisy from your side or maybe from the system. What is the distance, distribution of random point in our question environment? What is the distance, the distribution of distances and the targets we were looking at? It was actually San Francisco, so it was an entire street of the point cloud was over probably half a kilometer or so. And our measurements that we were doing were tabletop measurements were on the order of a meter distance. But they've done several kilometer measurements as well. So it depends on how long you're willing to wait for the scan and integrate points. It's how large a distribution of points cloud, how large a point cloud you can do. Does that answer your question? Shahzad, did you get your answer? Okay, I think the network from his side is a bit noisy. So any other questions from the participant? Yeah. Yeah, okay. Yeah, Hugo, you can unmute and ask please. Thank you very much for this presentation. Very informative. I have a quick question. I've tried making a, it's an open source Ramon spectrometer known as Ramon Pi using a Raspberry Pi. What were the requirements for the optical circulator for the FMCW? What are the requirements for the circulator? Those are commercial products you can get. You would want, I mean, the requirements are typically how much, so it's supposed to be light goes one way and then the other way. And it basically, it's the isolation that you don't want, if you're transmitting a strong beam, you don't want a lot of that strong beam directly going on to the return path. So you want isolations of, high oscillations of 30 dB or higher, typically in that respect. You want to be able to transmit a lot of power, so you'd like to be able to put up to watts through those circulators. Am I answering the question you're asking there? Yes, I think I put the optical circulator I have for the DIY Ramon spectrometer. I had a serious power issue which led me to believe that that was probably the main point. Thank you very much. Yeah, what kind of powers are you putting through it? It was around three watts for a laser. Yeah, it gets into trouble around then I think. Yes, thank you very much. You're welcome. Okay, I don't see any other raised hand. So, no, it's over to you, Joe. I guess we're going to take a picture really quick. How are we going to do that? I'm going to stop sharing. Okay, now I think everyone, every participant, they should turn on their video cameras and keep it turned on for a minute because there are many participants so I have to take the screen shots. First the first screen, then second, then third and fourth.


All right, everybody, welcome to this talk about platform availability. Schedule says, Cloud Foundry Availability. The ideas presented in this talk can be basically applied to any distributed system. So, platform availability is as good as a title. So, in this talk, what you're going to see is the idea of a continuous uptime improvement and in order to be able to continuously upgrade the availability of any system, you need to somehow measure its availability and in order to measure it, you have to define what availability means and how you'd like to calculate your metric. You don't see any slides, do you? Well, that's kind of strange. You would have said anything, right? Well, let me check the monitor settings. All right. Yeah, try to relaunch it again. Oh, you got to set the mirror if you want, you could do a mirror. No, I don't want to do that. Okay, I think because it's a, you may have to. Oh, just restart it. I think what it does is because there was a recorded session, so you can export it into a QuickTime movie and whenever you have a recorded session, for somehow you start the presentation, it doesn't show on the second screen. I don't know why, but it happened to me again. All right, so in this talk, continuous uptime improvement, and therefore you need to be aware of what availability means to you. It seems to be an easy question to ask, but it actually is a bit more complicated than it appears in the first thought. More than that, we're going to look into a framework on how to measure and calculate platform availability. There are many ways on how you can define availability metrics that are meaningful to you, so we are just looking into one example here, one methodology. Of course, once you have thought about what availability means, you still have to measure it, so we'll have a quick glance at that. In total, we are going to have around 25 minutes, I guess. I might be a bit longer than that. Last talk, so I hope you'll forgive me a few minutes longer. I'm trying to present all examples in the context of a cloud foundry, obviously, and the last topic, because it is related to availability, often asked by our customers is what are maintenance windows in the context of platforms and how does the availability and maintenance window concept play together. For example, we used to take down services for, let's say, a few hours or even a day to maintain them. You can obviously do that for more than platforms. We'll have a look at how this is affected today. A few words about myself. I'm Julian Fischer, CEO of NNINES. We are specialized in building tailored platform solutions based on cloud foundry and Kubernetes. What happens there? That's strange. The idea of the talk is, as I said, to enable a continuous uptime improvement, so wherever you start with your platform, it may change, your environment may change over time. For example, you get more customers, you introduce more data services, you whatever, deploy new versions of your platform, new cloud foundry versions. You had Kubernetes there. Depending on the size of your organization, this may be a simple monitoring metric you put together, so you'd be like, yeah, why talk about this at all? Or you are in a large organization where the management tells you what the availability should be, so you should have whatever, three, four, five, nines, and you'll be asking yourself, all right, and what does that mean? How do I actually come up with a number? That's meaningful. In the end, what we would like to establish as an organization is a process that continuously monitors measures and monitors the availability of the platform and then derives measures that could be beneficial or at least ensure that any other changes are not decreasing the availability. That learning loop pretty much looks like what the lean startup build measure learn looks like just for uptime. As I said, the question on what is availability is not as easy to answer, but the most common, let's say, way to express availability is by applying nines to it, and there's a table here using the example of the availability per month. Obviously, if you use that relative number in percentage relative to a year, you'll be having other downtimes on the right side, and you can see the more nines you have, the less downtime would be tolerated under a particular uptime requirement. People always ask us, where does the company name from? You can see one nines, two nines, three nines, and basically any nines. That's where the name comes from. I believe that you can design a system to a certain availability, and you should always have that in mind. So what is your uptime requirement? So, all right, let's pick one, maybe 99.9% for example. The question is, what are we actually talking about? Are we talking about a Cloud Foundry runtime? Are we talking about five of them? Are we talking about different environments? So if you really ask the question, what is your platform comprised of? You will see that, and we've been building and operating platforms for an eternity for customers. Each environment is different, and we have to, first of all, describe what the platform is about, and therefore, affecting the question and measuring availability is affected. So we need to define the system. We need to describe it somehow. What's the best way to describe a system with regards to availability is one of the questions. And we've been operating services, managed services, way before Cloud Foundry, databases, applications, application service, using Chef. That's strange, never seen that before. And one of the methodologies that seem to be a straightforward thing to do is just draw a graph. What are the components that comprise your system, and how do they depend to another? There's also a notation called reliability block diagrams. I think it's from electrical engineering. And the idea is that you will have serial and parallel compositions of components, and, of course, hybrid combinations of that. And whenever you bring that into the shape of a graph, or, I would say, in simple cases, a tree, you might end up looking at something like that. So this is, for example, how one of our Inunite's platform environments look like. Just you see that there's a platform. There's a platform. That platform comprises several platform environments, and each platform environment is comprised of several subsystems. So in this case, a base system where some of the shared components are. The Cloud Foundry subsystem, Cloud Foundry runtime. And in our case, our data services, which comprise eight different data services, their service brokers, their SPIs, and several other components to that. So we're looking into an environment with more than 100 components. And these components are organized in a set of subsystems. As you can see, the Cloud Foundry environment splits into the API, the Diego subsystem, the monitoring subsystem, and the service broker subsystem. And the data service themselves, they contain the actual automation that will be controlled by the service brokers. Now, I would try one thing. It's maybe like a screensaver that causes that. So I'll put in some electricity. I'll see whether this fix it. All right. So once we have figured out how the system actually looks like, and we have drawn such a graph, we can see what are the components we would like to look at, ideally down to the components that are atomic services. For example, a Postgres backing up the Cloud Controller. As you can see, for example, Cloud Controller is there, but there are subsequent components to this. I just removed that level of detail from the graphic, because otherwise it would have been too bloaty. There's already a lot of components in there. So we've been looking for a way that we can apply to every platform environment. And as I said, these environments might be very different. Let's say one customer, for example, he uses Cloud Foundry to deploy one application, and he uses Cloud Foundry to separate tenants. So each organization represents one tenant and has the same application in it as every other organization within that Cloud Foundry. So for example, for a customer like that, the availability of the Cloud Controller API to deploy new application versions is very different in meaning and importance compared to a public-facing developer platform where developers will start calling you in case they cannot push their applications. So we've been looking for a way to express both the composition of a system as well as the importance of their particular subsystems. So the first aspects of it describe how do you express dependencies of, well, let's say, within one of your subsystems, more elementary subsystems, such as Diego, for example. So in Diego, you have a different cells and depending on how many of the cells are there, your applications will be up and running or they won't. Another type of dependency would be the serial dependency where you have two components and both components need to be present. So there are some calculations or formulas you can apply to that. I didn't fix it. And in this case, you can see that assuming 99.5% availability of each component, if you have a serial dependency and you look at that dependency over a longer period of time, that a serial combination of those dependencies will result into a lower availability in total. So in this example, you lose about half a percent. So of course, because if one component fails and it's a serial composition, the overall service won't be available. And because the other component fails too, the combination of the two is less than. Actually, that's a pretty nice feature. It keeps me going, right? So a failure of one component implies the failure of the entire service. So obviously, there's a second version of it where the components are in parallel. And what this means is that each component assuming the same availability, 99.5%, the service will be available if at least one of the components is present. So for example, you have deployed your application and you have two instances and let's assume you don't utilize both instances to a full degree but distribute incoming requests. If one application dies, your application request will still be served is one of the two application instances survive. And there's a formula for that too which basically means that you only decrease the availability if both of the components have been failing together and the combination of the two will increase your overall availability. So assuming that you had 99.5% in the beginning, the parallel composition on that nearly gives you 100%. So the compound availability of these increases, obviously, you want to have situations where you have a little bit more complicated topology where you put together some things in serial and other components might be in parallel. So in this example, you can see that you'll have the serial dependency which is the outer structure and one of the components is comprised of a parallel structure. So all you do is just take the formula and put it in braces into the formula. I think that's basic mathematics. And the result is that as you can see, the overall availability is pretty much decreased because of the dominance of the serial sequence by the four components being in a sequence. So each assuming 99.5% availability, the dominance of the serial composition makes up the decreased availability. So there are situations, for example, with database clusters where you actually want to express a partial availability where you can lose a certain redundancy and still your servers would be able to survive. So a MongoDB replica set or a Postgres asynchronous replication with three nodes and a quorum-based leader election may survive the failure of one of three nodes. So in order to express the availability, you could, for example, apply an equation like that, providing an example here. So n would be the number of the nodes in the cluster. It's three replicas. And you need at least two of the nodes for the service to be available, which would be m, m is equal to two. Assuming that each node has the average availability of 99.5%, you will see that the overall availability is also close to 100%. So you can increase, for example, the number of replicas to five, then we'll have five nodes and maybe only need three nodes to be available. And you can see that that gives you the possibility to survive even more node failures and still remain available all the time. So as I said, the serial parallel and composite availabilities is usually applied to more basic components, components where there's a direct relationship and the nodes do somehow equal or serial independent stuff. In database systems, usually the nodes are kind of equal that formula applies. But as we can see in that diagram I showed earlier, the dependency graph, that the subsystems are comprised of very different components. And the question is how do we actually come from the service availability of, let's say, a database or a Diego cell to the availability of the entire platform. So you need to put in some thought and we came up with the kind of an obvious thing to do. You model the overall platform availability by recursively going through the dependency graph and determining the best applicable formula to each of the compositions you will find there and then subsequently build up your metric from it. So I try to be visual about that because that sounds like a lot of theory but it actually isn't. So we're always coming again to that graph that shows you the platform, looking at one platform environment with a base system, a cloud foundry, and the United States data services and the miscellaneous components we'll just neglect for now. So basically you determine the availability for the sources in the dependency graph. So at some point you need to measure the availability of one of the components in the graph before you can then compound them into and compose them into compound services. And you would then, yeah, somehow bring them together and we'll have a look at how this works. So you basically go through the graph, well you could do that bottom up, that's basically how the data will flow, but in this talk we'll go the other way around and look at it from top to bottom. So why do we do that? Let's look into, you have one region at this point of time, let's say AWS, US East and there you have your platform. The platform usually comprises of several environments.  So how do you express the fact that these environments are not equally important? And you could apply other formulas to that, I'm pretty sure, but one simple approach is to use weighted averages. So you basically sum up the availabilities and divide it by the weighting factor. I prepared an example, so for example, if you have a development, a staging and a production environment, you could arbitrarily weight them to express their relative importance to your overall availability. So for example, this is very neat if your boss tells you you need 99.9% availability and you can come back to them and ask, well, all right, what do you mean with that? But that question, I guess, will be without an answer. He will just be angry because it's a question that's not as easy to answer. But if you come back to him and you tell them, well, relative to your production environment, how important is staging? You would say, well, I don't care about staging, but maybe your developers are or your platform engineers do care about that. Maybe there is impact to your overall development if this environment isn't there. So this will allow you to apply relative weights to each of your environment that will be then multiplied against its availability. So you calculate the availability relative to the importance of each environment. So to be more visual, put their calculations, if you want to download the slides afterwards and go through the calculation in greater detail, you're free to do so. So basically each environment has a weighting factor and therefore you can determine the overall availability. As you can see in this example, we had a very good production availability of nearly 100%, but the platform availability has been dragged down by the relative low availability of the staging environment and this is highly weighted. So maybe you want to change that weighting factor to show off towards your boss. So in this illustration shows that we have come up with the weighted combination of the individual platform environments as the way to determine the overall platform availability. So we can now step down one level and we just look at how can we combine the subsystems within a cloud foundry environment, which comprises of the pink cloud foundry runtime and the NNINES data services in our case. Because in order to applications to be available, you also need the backing services so that these two are equally important can be expressed in a similar way, in this case, a weighted average again. So as you can see, you're then here on level two and you can basically repeat that, looking into the availability of the cloud foundry runtime, which is comprised of the API, Cloud Controller and UAA, the monitoring subsystem, additional components to monitor the individual components, the Diego subsystem, as well as your service brokers, for example. And then applying the same strategy again, you have your weighting factors and for example here, you could express that use case I was mentioning. So the customer who has this one application and just uses cloud foundry as a multi-tenancy enabling tool might, for example, weigh the cloud foundry API way lower than a customer with a public facing platform. So the idea was to come up with a quite simple tool that allows you to express the individual requirements of the platform and come up with an availability metric that has meaning in the particular context of that one platform, instead of coming up with a calculation that may be not meaningful or may not be meaningful in the broader context. So yeah, as you can see, we basically step down one level by the other and you can repeat that. So the weighted averages are actually interesting if you have subsystems with different components that may be of different weight in different scenarios. So you go down that path until you hit one of the components where you actually want to use that serial and parallel dependencies where you possibly can also measure the available instead of just calculating them. So the question is how do you obtain availability from atomic services and the answer is obviously you measure them. So the monitoring of availability is very important as part of your input. And there's another aspect beside of having availabilities of components that you can then put into your fancy formulas is also important that the availability monitoring service input for the support team to diagnose platform failures. So for example, if you have trouble with your cloud controller, this could be caused by the postcards behind the cloud controller. And if your availability monitoring is good enough, you can find out that you'll have a problem with your database instead of your cloud controller where actually the first error came from. So you do not only know that you have a problem, but you also would like to have an indicator where this problem might come from and subsequently tell your platform operators what to know in order to conclude a informed decision. So in Cloud Foundry, we I guess all use a Bosch and therefore we use Monit. So that's a pretty neat tool and it's very good to monitor atomic services. It allows you to have process cell feeling. It monitors the existence of processes which is absolutely insufficient because if you're pretty sure you've seen data service doing their processes present, but they're not responding or web applications could be the same way. So it might be necessary to ask the question for a certain component, how do I determine the availability of the component? And the conclusion usually is that you need to perform some kind of functional testing, for example, connecting to the database, querying whether a certain schema is there, just to see whether at least heuristically the system is available. And that leads to the question how much load do you want to expose your system to just to perform that particular check which also determines how often the check can be executed. So there's a certain optimization problem here, but I mean that's really depends on the component you're looking at. So while monitor is pretty interesting, the bigger picture usually comprises a monitoring tool such as Prometheus could be anything else serving the same purpose where you actually go back to that diagram. And for each subsystem, you've got that fancy formula yourself and you translate that into a markup that will represent that formula. And that will result into a visual dashboard shows you the availability of the systems and subsystems that represent the craft if you've seen earlier. So the good thing here is that you can basically traverse your dependency graph in your monitoring system, but just clicking at those availability metrics, and you will again then go to one level deeper and you can see the dependencies of that particular subsystem, and so on. So that helps you a lot to determine if an availability seems to be odd to find out where it actually comes from. So over the time by applying that technique, you will have more and more dashboards assigned to those subsystems. So again, that you can do that until you come to the more elementary services. And I'd like to highlight one thing that is the availability of a particular subsystem, let's say the Cloud Foundry runtime as we've seen may go down to the question on are the availability of the subsystems available? But at the same time, maybe users will say like, well, I don't actually care about your fancy metric. What I care about is can I deploy an application or can I create a service instance? So you may want to look into a monitoring of availability more in the context of use cases than in the context of just determining a fancy number, because that's actually what the value for the customer is. Does the system fulfill what it's supposed to do? So the example here, can I create a Postgres instance, may involve, do I have the service broker, does the virtual machine as it has storage attached to it or their local resources or the dependencies of that service present? So you can basically look at the use case and give a use case based monitoring by looking at that dependency tree for that particular use case instead of the overall subsystem and conclude the healthiness of the use case. This is especially important when you have scenarios where particular use cases are way more important than others because it's a special use case. Having knowledge around the applications running on the system, for example, is one of them, where you know that that particular database is more important than the other thing or we have a CI CD pipeline running at a high pace and I really need that CF push experience to be there. So another interesting thing is to perform availability monitoring during upgrades. So I'm giving you an example. We repeatedly run upgrades here using the availability of the data service subsystem and it's interesting to see what actually happens during the upgrade. How does the upgrade affect the availability of the overall system? We do those tests and staging, for example, to conclude and report to customer what the actual impact might be. As I said earlier, the question on how do maintenance windows look like today is a question that we've seen repeatedly with customers. So while the definition says it's a period of time designated in advance to perform preventive maintenance that could cause disruption of service, I think the question is, what does it mean for the application platform? Because one of the reasons to move there is to avoid outages and we're on the cloud and the cloud never fails. So you already see where this is going. Platform wide outages are absolutely unacceptable and they are unnecessary too. But then you've got those fancy forms in your company and that 300 page handbook, that's about whatever, service security and standards how to run software systems. So you need to fill out that paragraph that's about maintenance windows. I would say the reality of maintenance windows nowadays is that we are looking at platform environments with 3000 virtual machines managed by Bosch, for example, and how would you perform an upgrade in such a system? I mean, you have several subsystems as seen earlier and for example, updating Diego would mean that you'll just take away a virtual machine and those applications being affected would be created somewhere in the cluster. So in that particular example, you can see that you can take away up to two cells before the system will actually be experiencing significant problems from failing Diego's. So an inflight limit of one would leave enough capacity for applications to be deployed, while an inflight limit of two would already fully utilize the system. Wouldn't be a good idea to apply that in that simple example. On the data service side, you can see that a rolling upgrade through the data service instance for clustered instances, such as Postgres, you will see failovers towards the application, but no outages. If you upgrade a single node Postgres, recreating that virtual machine during the process, you will see an outage that might be a five or 10 minutes depending on the upgrade. So what this is saying is that the maintenance window is about setting your inflight limits and setting the redundancies in your system accordingly and that you should design your system to your uptime requirements and that within that process you have to determine the redundancy and weigh it against the infrastructure costs you're looking at. So yes. So summing it up, there is a systematic way to define platform availability. You still have the possibility to tailor towards your specific environment needs and you can actually make promises towards your manager to have environments 99.99% available and you can also make sense of such a requirement and come back with some more explanation on what this actually means by telling him how you weighted the individual components, verifying that the way you weighted it represents the interest of your customers or your organization. So the platform dependency graph was a graphic we've seen repeatedly and so that step of analyzing the dependencies in your system is one of the most crucial one. So you then define and measure the availability of atomic services. You compose and weight the subsystem availability and derieve the metric from it. Implementing your availability system in a way that it gives you a differential diagnosis is meaningful and as I said the calculation of availabilities of subsystems is usually a composition of other subsystem availabilities a recursive path towards something you can measure. So in order to come into a learn loop you'll have to you know derieve insights from what you see for example looking at the upgrade see how it affects the availability during the upgrade and maybe come up with a better idea so that less impact is seen. We see in large system a continuous maintenance going on so you're just done with one update and basically the next update is already to be prepared so there are waves of updates constantly going through the system so it's meaningful to design a system capacity accordingly so that these update waves won't interfere with your customer workloads and that actually completes my talk for today. I'm ten minutes over my time. No not so many people left so I hope you enjoyed it. Here if you have questions feel free to ask. Regarding the serial dependencies you mentioned this is basic probability right but one prerequisite is that the events are independent is this always the case because one outage might influence another outage of another service or even both could have the same root cause and then the calculation is wrong. Well yes the question is always to what degree do you want to calculate the availability in the what degree do you want to measure it so I simplified and said you you measure basic components and you compose the availability of subsystems if you have an ability to measure the availability sorry of the subsystem instead you can actually reduce that error you were mentioning also we didn't talk about the infrastructure availability for example network and bandwidth and how this may affect your cluster availability postgres a good example if you have a network trouble that causes a split brain then even if all the three nodes are basically healthy you could have an outage of a subsystem so yes you're right there are mistakes in that procedure that you'll be you'll have to be aware of it is an answer to a question that we have this specific requirement where the management said we want to have that availability of the platform and the answer was or the our job was to determine a way how to give them the availability and still provide them a meaningful explanation a way that you can explain to the customer what this actually means does this perfectly give you all possible scenarios surely not but we have at least a continuous monitoring now we have a history of data and we can see for example also applying different techniques doing upgrade and see whether we can have been able to reduce the impact of upgrades and this is the purpose of what I have been presenting but there are many ways you could improve that all right then thank you very much