I welcome you all for module 3 lecture 4. In this lecture, we will be discussing about the various factors favoring the loose tolerances and tight tolerances. We will have the discussion on the selection of different kinds of fits and the assessment of the fit and tolerances and how we can calculate the tolerance unit value. Also, we will discuss about the geometrical tolerances. Now, I am showing few engineering parts, the bearings which require very fine finishes and very tight tolerances. We can see here, we have some bearings, ball bearings with very fine finish. So, it is very essential that we have to control the dimensions and it is also necessary that we have to control the features, geometric features. For example, the roundness, flatness, tightness, etcetera, etcetera, so that they function in a proper way. Here, we have fluid film bearings used in hard disk. We can see that they have very fine finishes with very tight tolerances, so that they function properly without much run out problem. So, they require very fine I t grades like I t 4, I t 5, etcetera, so that their functioning will be proper. Now, this table shows the factors in favor of wide and narrow tolerances, when we should go for narrow tolerances, when we should go for wider or loose tolerances. The factors in favor of loose tolerances are given below. They increase the yield in manufacturing and there will be fewer defects are produced and fabrication of toolings like dies, jigs, etcetera will be very easy. So, tools will be, they will not be very costly because of the loose tolerances. We need not have to use very precise machining processes. So, the production cost of the parts will be less and setup and tooling adjustment will be very easy if we have the loose tolerances and then fewer production operations may be needed. We need not have to go for very finer finishing processes like a lapping, etcetera, etcetera. A simple fine turning or rough grinding will be enough and the less skilled and lower cost labor can be used. If we select very tight tolerances, what happens is we have to go for the lapping process, super finishing process, diamond turning process like that. So, in such cases, we have to use very skilled operators. If the tolerances are wide, we can use semi-skilled operators so that the labor cost will be less and also the machine maintenance will be reduced and the need for inspection will also be reduced. Cost of inspection will be reduced. The reason is we can use normal measuring instruments and if we provide very tight tolerances, then we have to go for very fine precise measuring tools. So, investment on inspection cost will increase if we have tight tolerances and then overall manufacturing cost is reduced. Reason is the not so precise machines can be used and semi-skilled operators can be used and the inspection cost will reduce. So, due to this, the overall manufacturing cost also will reduce and what are the conditions favoring tight tolerances. See, when we provide very appropriate tight tolerances, the parts interchangeability is increased in assembly. That means we can randomly select the mating parts and we can easily assemble. So, which may not be possible if the tolerances are very, very loose. And then fit and finish of the assembled product will be better and the aesthetic will also be better if we have tight tolerances and then production functionality and performance will be improved and the products produced will be durable and they will be reliable in service. And the serviceability of the product in the field is likely to improve due to increased parts interchangeable. That means the components to be replaced, they are readily available in the market like bearings, belts, etcetera, etcetera, taper pins, different kinds of fasteners, they are readily available. So, we can purchase them and we can replace them. So, interchangeability aspect will improve and product will be safer to use. Now, we will move to steps in assessment of limits and fits. That means how we can assign the proper tolerances and how do we get the proper fit and how to select the proper fit. So, these are the steps followed for assessing the limits and fits. The selection of proper fits based on functional needs, that means what is the basic intention of the product, where it is used, whether running clearance is required or very tight clearance, tight fit is required or very wide tolerance and very wide clearance is required. So, depending upon the functionality, we have to select proper fits, whether we want clearance fit or transition fit or interference fit like that. So, it basically depends upon the functional needs, what is the application of the meeting parts. And then once we select the proper fits based on functional needs, within that we have to select what type of hole is required or what type of shaft is required. For example, if we select clearance fit, within that what is the hole that whether we require H hole or B hole or C hole. Similarly, when they come to the shaft, what type of shaft is required, H shaft is required or M shaft is required or B shaft is required. So, that we have to select. And then the selection of tolerance grades for hole as well as for shaft also, we have to properly select, whether we require H7 or H8 or if it is the very precise operation is required, very proper location is required, then we may have to go for I t 4, I t 5 like that. And if it is for the manufacturing of gauges used for inspection purpose, we may have to go for I t 2, I t 3 like that. So, depending upon the again based upon application, we have to select proper tolerance grades for hole as well as for shaft, which will decide the amount of the tolerance on the hole and shaft. And then we have to calculate the standard tolerance I for a particular combination and then calculation of limits on hole and shaft. That means, once we know what is the type of hole and what is the type of shaft and then what is the tolerance grade we are using and after finding the standard tolerance value, then we can fix up what is the upper limit for the hole, what is the lower limit for the hole. And similarly, what is the upper limit for shaft and what is the lower limit for the shaft, those things can be calculated. And then after once we find the limits for hole and shaft, we can calculate what is the amount of clearance, what is the maximum amount of clearance, what is the minimum amount of clearance, if it is clearance fit. And then we can if it is interference fit, what is the maximum interference, minimum interference and if it is the transition fit, what is the maximum interference, what is the minimum clearance, such things can be calculated. And once we calculate all these things, So, we can prepare the drawing, we can mention all the tolerance etcetera etcetera, and that drawing can be supplied to the manufacturing unit for the making of the products. Now, let us discuss about the selection of fits. Now, again basically the fit depends depends upon what is the application, whether the fit we have to select for the pulleys, and then motor bearings, and then heavily loaded bearings, and whether we are assigning the fit and tolerance for lubricated bearings or gear boxes, loadage shafts etcetera etcetera. So, based upon the application, we can select what is the type required, whether we can go for large clearance, loose clearance, and then normal running clearance, precision running clearance. So, once we fix up the type of fit that is needed, then we can go for what is the shaft. So, this is basically a whole basis system. So, H capital H whole is required. Now, we have to select the shaft, what type of shaft is required, whether A shaft is required, B shaft. See, when the large clearances are needed for general usage, then we go for ABC shafts, which will provide very large clearances. And then for accurate bearings, we may have to go for GE shaft, and then also depending upon application, we have to properly select what is the tolerance grade, whether 4 is required, 5 is required, 6 is required, 8 is required. So, like this, the such tables we can use for selection of fits. And preferred clearance fits are mentioned here, H11, C11, H9, D9, so and then H7, H6, like this, these are preferred. So, once we fix up the clear, what is the type of shaft and grade, then we can select the appropriate preferred, nearest preferred clearance fit. Similarly, we have tables available for selection of transition fits, again based on the whole basis system. Again, we can see there are many application are mentioned here, very accurate location, couplings, gears, and then precision joints, forced assembly sometimes may be required and semi-permanent or type fit assembly we may have to design. In such cases, we have to appropriately select the fit, slight clearance is required or very little clearance is required, that we have to find. And then we have to appropriately select the shaft, whether K is required, M is required and N is required. And then we can also select the IT grade. And then we have the preferred transition fit. So, we can select the preferred fit also. Similarly, we have interference fit. Again, some applications are mentioned here for fixing bushes, we may go for interference fit, for tight press fit and then valve seating and then permanent assemblies. So, in such cases, we go for interference fit. For example, for permanent assembly with H, capital H whole, we can use this T shaft or U shaft. And for valve seating, scholars, etcetera, we can go for S shaft with tolerance grades 5, 6 or 7. And then again, we have the preferred interference fits. We can select the type of fit out of these preferred interference fits. Now, after studying all these basics, we will see some numerical examples. I have taken an example here. We follow all the steps. For example, selection of fit and calculation of tolerance unit, etcetera, etcetera, so that the basics can be understood clearly. Now, the problem is the diameter of the shaft is 70 millimeter. That is the basic size or the design size of the shaft is 70 millimeter. And then tolerance grade is H 8 for whole and F 7 for shaft. So, H whole with I T 8 grade is used and for shaft, F shaft is used with I T 7. So, the tolerance grades and type of whole, they are already mentioned in the example. Now, what we have to do is, we have to calculate the standard tolerance unit and then whether there is any fundamental deviation. And then, what is the upper limit and lower limit for shaft? Similarly, what is the upper limit and lower limit for whole? That can be calculated. And finally, we can say whether the type of fit obtained is clearance fit or interference fit. Now, we have to find fundamental deviation, tolerances for whole and shaft and limits of size for whole and shaft. Also, we have to mention what is the type of fit. And also, we have to calculate maximum and minimum interference or maximum and minimum clearance. Depending upon fit obtained, we have to mention what is maximum interference or clearance and what is maximum type, maximum amount of these interferences and clearances. Now, the solution is given here. Calculation of standard tolerance unit. So, we can use this equation i is equal to 0.45 times cube through tough d plus 0.001 times d. So, where d is mean diameter. That means, we know that the basic size is 70 millimeter and then where it falls, in what step it falls that we have to see that we can do using table 7. 70 mm, it falls in the range of 50 to 80. So, now we can find the mean d that is cube root of I am sorry square root of 50 times 80. So, this will be equal to 63.25 millimeter. This is the value of mean diameter. Now, we have to insert this d in this equation to find the tolerance unit. So, the value of d is inserted here 0.45 times cube root of 63.25 plus 0.001 times 63.25. So, this will give us 1.865 micrometer or 0.0018 millimeter. Now, after finding this i, we can find the tolerance values for shaft and wall. Now, we are using F7 shaft. So, tolerance value for I t grade 7 is equal to 16 i. So, this we can get from table number 5. So, now the tolerance value for the shaft is equal to 16 times i, where i is equal to 0.0018 millimeter. So, this will be equal to 0.03 millimeter. Similarly, we can find the tolerance value for whole. So, we are using H whole with I t grade 8. So, tolerance value for I t 8 will be 25 i and then the i value we have already calculated that is 0.0018 millimeter. So, tolerance for shaft I am sorry tolerance for whole will be equal to 25 i that will be equal to 0.046 millimeter. Now, after finding the tolerance unit and tolerance values for whole and shaft, we can find the fundamental deviation. Since, we are using the whole basis system, the fundamental that is H whole we are using. So, fundamental deviation for whole is 0. Now, we have to find the fundamental deviation for the shaft f. Now, from the table number 4, we can get this equation for getting the fundamental deviation for f shaft. So, for f shaft fundamental deviation that is upper deviation is equal to minus 5.5 times d to the power of 0.41. So, we have to feed the value of d that is 63.25. Then, we get fundamental deviation which is nothing but upper deviation as 0.030 millimeter. So, once we find the fundamental deviation tolerance values, we can fix up the limits for shaft and whole. Now, higher limit for shaft is equal to the basic size of the shaft that is 70 millimeter minus fundamental deviation. So, that is 0.03 millimeter. So, we get higher limit as 69.97 millimeter. Similarly, for lower limit of the shaft, higher limit of shaft minus tolerance that is higher limit is 69.97 and the tolerance value for the shaft is 0.03. So, this will give us lower limit of 69.94 millimeter. Similarly, for whole we can find lower limit and for limit. So, in this case lower limit for whole is 70 millimeter. Reason is fundamental deviation is 0. That means lower limit of the whole will be equal to basic size that is 70 millimeter and higher limit can be calculated by adding tolerance to the lower limit. So, we get 70.046 millimeter. Now, we can show this graphically like this. We have a 0 line. This is a 0 line. From this 0 line, we show all the other dimensions like tolerance value, basic size, etcetera, etcetera. Now, we are using H8 whole. So, this is H8 and for H8 whole, we have calculated the tolerance value. So, tolerance for H whole is 0.046 millimeter. That is this tolerance value is 0.046 millimeters and then coming to the, this is the lower limit for the whole which is equal to the basic size 70 millimeter. Since the deviation is 0, the lower limit for the whole is equal to the basic size and we have to add this tolerance value to this basic size to get the upper limit of the whole. Then upper limit of the whole is 70.046 millimeter. This is the upper limit. Now, we have F7 shaft. So, this is F7 shaft. With the tolerance value of tolerance value for F7 shaft is 30 microns. So, this is 0.03 millimeter and also the fundamental deviation that is upper deviation. So, upper limit of the shaft is nearer to the zero line. So, this is upper deviation and we have calculated the upper deviation for the shaft that is 0.03 millimeter. Now, using this tolerance value and this upper deviation, we can fix up the limits for the shaft. So, that we have already found here, higher limit of the shaft. This is the higher limit, H limit for shaft. So, higher limit is 69.97 and then lower limit we get at this point. So, this gives us the lower limit. That means from the upper limit, we have to deduct this tolerance value. Then we obtain the lower limit. So, this is the maximum clearance. So, this gives us the maximum clearance. That means, we get the maximum clearance when the shaft size is equal to the lower limit and hole size is equal to the maximum size. Then we get the maximum clearance. So, what we have to do is, we have to add this tolerance for shaft and then we have to add this fundamental deviation and then we have to add this tolerance for hole. Then we get the maximum clearance and this difference between the minimum size of the hole and maximum size of the shaft will give us the minimum clearance that is equal to 0.03 mm. Now, we can compare these values, the shaft limits and maximum clearance, minimum clearance with the table 3. The basic size is, we are using 70 millimeter. So, we get 70 millimeter between the 60 and 80. Then we have calculated the tolerance for hole is 46 millimeter. So, we are using h 8 hole. So, we have h 8 hole here. So, now we can see here, this difference is 46 microns for 60 millimeter basic size. Similarly, we have same tolerance value for 80 millimeter basic size. So, for 70 millimeter basic size also, the tolerance value will be equal to 0.046 millimeter and similarly, for shaft, the tolerance value, we can see here is this difference is 30 microns. Similarly, for this 80 millimeter size, the tolerance value is 30 micrometer, 0.03 mm. So, for 70 also, same value will be there. Then we can also see the maximum clearance and minimum clearance. All these are clearance fits. You can see minimum clearance is 0.03 millimeter and maximum clearance is 0.106 millimeter. We can observe here. Minimum clearance is 0.03 millimeter and maximum clearance is 0.106 millimeter. Like this, we can calculate the values or if ready tables are available, we can use the ready table to fix up the limits for hole and shaft and to get the type of fit. Now, we have a special case of tree lobe. Now, in all the previous examples, what we studied is based upon the hole size and the shaft size, we get a particular type of fit. That means, if shaft is smaller than the hole, we get clearance fit. If the shaft is greater than the hole, then we get the interference fit and sometimes we get transition fit depending upon the actual size of the hole and shaft if the tolerance zones are overlapping. Now, this fit can be calculated by measuring the actual sizes of hole and shaft or if we know the tolerance zone for hole and shaft, we will come to know whether we get that clearance fit or interference fit. But sometimes what happens is, the shaft will not be circular. That means, we may get some lobes like this. So, this happens normally in centralized grinding wherein we have a supporting roll and then we have the workpiece and then we have a rest, a blade to keep the workpieces and then we have the grinding wheel. So, if the workpiece setting is not proper or the blade height is not set properly, then there are chances that we may get the some errors like this. We may get lobed shafts. Now, if we measure this diameter using a micrometer, that means, 2 point contact method, everywhere it gives same value. So, micrometer measurement will not give us whether there is any lobing or not. If it is elliptical shape, it gives the difference we can find the max, this is the minimum diameter and maximum diameter. Then, we can find that if there is any difference, we can find that there is low mobility is there. But for 3 lobe, the micrometer measurement will not indicate whether there is any 3 lobe or not. So, we just measure the diameter and we measure the diameter of the hole and then we try to we calculate the type of fit. What happens is, say we have a diameter of hole is say 20 point 0 2 millimeter. This is the diameter of the hole and then we have micrometer measurement gives that the diameter of shaft is say 20 point 0 3 0 millimeter. So, this is the diameter of the shaft obtained by a micrometer. Then, what we can conclude is the diameter of the shaft is greater than the diameter of the hole. So, immediately we say that the type of fit what we are going to get is interference fit. But in actual practice, when we try to insert this 3 lobed shaft into the hole, it will enter. So, how this is possible? See now, if we try to insert this, so this is the center of the hole O 1 and then this is center of the shaft O 2. Now, when both the centers coincide, then the situation will be like this. That means O 2 is coinciding with O 1, then there will be interference. But in actual practice, what happens is, we have this circle with O 1 center and when we try to insert this, now we can see that there is some clearance. So, what happens is, this shaft will move down and then it will enter into the hole. So, situation will be like this and O 2 will be somewhere here. So, actually we get instead of getting the interference fit as per the measurement, we get the clearance fit in actual practice. So, we should be careful in fixing, in getting the fits. That means, mere dimensional measurement of the or the specification of dimensional tolerance for hole and shaft is not enough, we have to specify the geometrical tolerance also. So, what is the amount of error that can be allowed on the straightness or flatness or roundness or cylindicity. So, geometrical tolerance is also very important to get proper type of fit and for proper functioning. So, now we will have a discussion on the geometrical tolerance. Now, you can see here, the straightness of an edge, say we have a line like this. So, we have a line like this, but in actual practice, when we measure, it may be like this. So, it will vary, the points will vary. Of course, this gap will be very small, it will be in terms of few microns. So, now it is very difficult to machine a perfect straight edge. So, we have to allow some tolerance for the straightness and that we can do by specifying, what is the gap between these two lines. Say, it may be some like 0.01 millimeter or 0.02 millimeter like this depending upon the application. So, straightness is also specified on the drawings. So, it is to control straightness of a line or axis or a surface. So, basically it is gap between two parallel straight lines in a plane containing the considered line. That means, the line may be like this and what is the maximum deviation on the straightness that is allowed. So, that is mentioned like 0.01, 0.02, etcetera. So, now the symbol used for specifying the, say we have a cylinder like this and we will be having so many generators and we want the straightness of this should not exceed say 0.03. So, we have to specify like this.  So, that value this is tolerance value and this is the feature. Straightness this for straightness like this we specify the straightness. Similarly, we can specify the flatness say we have a surface like this. For example, the guide way of lathe or any machine tool and it should be flat it is necessary that it should be straight as well as it should be flat. So, that we can specify using this symbol, flatness symbol like this. So, we have to specify the what is the feature flatness in this case and then we have to give what is the value whether it is 0.02 millimeter or 0.01 millimeter like that. So, this is how we specify the flatness. It is basically to control the surface flatness and it is area between two planes. So, we have two planes here and the surface in question. So, this is the surface in question all there are many high points and low points on the surface. All the high points and low points should be contained within these two planes which are separated by the given tolerance value in this case 0.02 millimeter. Now, similarly we can we specify the roundness what is the roundness that is allowed. It is basically to control circularity error in the plane in which it lays and then how it is specified we use two concentric circles. So, that area between two concentric circles gives us the roundness that means. So, we have a shaft which is necessary that it should be round, but in practice there will be some variations low points and high points will be there. All the low points and low high points on that particular round part should be should lay within these two circles. So, this value is mentioned what is the amount of tolerance that is allowed whether it is 0.01 or 0.02 like that that value is mentioned and we specify the roundness like this we use that symbol and then we give the value. So, this is how we specify the roundness. Now, we will move to the perpendicularity sometimes it is necessary that the two lines or two axes or two surfaces should be perpendicular to each other. There will be a datum surface and then there will be a working surface. So, that angle between this working surface and this datum surface should be 90 degree. So, that is known as a perpendicularity. Now, how it is specified say we have an angle plate like this and this is the datum surface. So, it is shown like this say A surface A. So, this is the datum and then we have to specify the tolerance for the perpendicularity. So, what we do is we draw a line parallel to this surface and then we mention what is the amount of perpendicularity error that is allowed. So, for example, 0.01 millimetre that means any point on this particular surface should lay within these two planes the surface can be like this or it can be like this or it can be some rough surface like this all points should lay within these two parallel lines. So, the high points low points can be like this with reference to this A and then cylindicity is also important. Now, say we have the symbol for cylindicity is circle with two parallel lines. So, this cylindicity is to be controlled in many engineering applications. So, this symbol is used to control roundness, straightness and parallelism of the cylinder it is a annular space between two coaxial cylinders. So, annular space between two coaxial cylinder we have two cylinders and separated by some distance this is the tolerance value may be 0.01 millimetre or 0.02 millimetre something like that. Now, all the points high points and low points on the complete surface of the cylinder should lay within these two circles and the shape can be like this may be a taper or it may be taper in the other direction or it can be some bell shaped double bell shaped or it can be drum shaped any shape within all the variation should be within this low ball tolerance. Now, how this is specified we have a cylinder like this and then we mention what is the feature in this case it is cylindicity and then we mention what is the value in millimetre. So, this is how we specify the cylindicity that means you take any generator or any circle all the values all the high points and low points should lay within this range and then we have profile of a line say we have our piece like this and then we have a profile like this some radius is there. So, now we have to control this profile variations for that we have to draw we use this symbol the meaning is there will be two arcs parallel to each other parallel arcs separated by some distance and then what is the tolerance is given that means all the lines on the profile on the high points and low points on the profile should lay within these two arcs separated by the tolerance amount in mm. So, that is profile of a line similarly the angularity sometimes we have to maintain the angle between two surfaces or two lines axis and angle is other than 90 degree. If it is 90 degree then we say it is perpendicularity other than 90 we say angularity. So, say we have a part like this and then this is the working surface this angle is to be controlled with reference to this datum surface. So, what we do we draw another line parallel to this and then all the high points and the low points on this particular surface should lay within this tolerance that is allowed it can be 0.01 or 0. depending upon application we can specify what is the deviation from angularity and similarly we have the symbol for parallelism. So, we have a work piece like this and work piece like this and then this top surface should be parallel to this datum. Datum is shown like this. So, this is the datum say A surface is datum and all the points on this particular surface or line should lay within these two lines which are separated arcs are separated by the given amount of tolerance. For example, 0.01 mm high points and low points all should lay within these two lines or two planes. Now, how this is designated? So, it is shown like this we have to use the parallelism symbol and then we have to give the value what is the tolerance that is allowed and then we have to specify datum with reference to which plane this should be parallel. So, that reference or datum surface also we have to specify and then we have another feature concentricity say we have two steps diameter steps like as shown here and then the axis of this particular part should be concentric with the axis of the other part. So, and if there is any deviation then what is the amount of deviation that is indicated by using two circles concentric circles and that is specified like this. So, we have this is the reference datum say this is A surface A and then this axis should be parallel to this or concentric with this within the certain tolerance. So, we specify like this this is the symbol feature symbol for concentricity and then we have to specify what is the tolerance and then we have to specify with reference to which reference or datum like this we specify the concentricity and then similarly profile of a surface sometimes we need to control the profile of a surface. So, in that case what we do is we use this particular symbol the meaning of this is the we have two surfaces like this separated by the given tolerance amount for example, 0.01 millimeter all the points on the profile surface should be within these two surfaces separated by the given amount of tolerance. So, now how to specify the profile tolerance is shown here we have to use this symbol and then we have to mention what is the deviation that is allowed. Now, in this lecture we discussed about the various aspects like selection of fits calculation of tolerance unit value and then what are the factors favoring loose tolerances and tight tolerances we also discussed about the various geometrical tolerances for geometrical features. In the next class we will be discussing about the various positional tolerances how to specify positional tolerance and then we will also say some numerical problems.


All right. Hello. And welcome back to campus. So this might be your first. Is this your first time back in person in a very long time? Or no, we've had some other classes. Oh, okay. Two years and a half. All right. Well, welcome back to, I guess, back to almost normal after like two years. So to some of you that might be scary to some that might be amazing. No matter what it is, we'll work through it and try and make this semester actually good. So a little bit about me. Hello. I'm John. I prefer just John. You don't have to be super formal with me. My last name as you can see is a bit of a disaster. So no one can probably pronounce it. The easiest way is to pretend the Y and the O aren't there. So elf, like at Christmas time, sin. And then if you want to remember how to spell it, you just throw a yo right after the E. And then you can spell my last name. So hopefully you don't need to spell it. But if you do need to spell it, that's an easy way to remember. But easiest way is just to call me John, right? You can use whatever you're most comfortable with. If you want to say professor, that's fine. That's kind of weird. So I am just a brand new hire. So please be gentle with me.  Hopefully that means I can change stuff, make things for the better, improve. You'll probably see if you went through lecture slides, there's already some new stuff. I've seen some of you already have found my stuff already somehow. I don't know if you're here, but if you are, congratulations. So yeah, I just started in July. So I'm kind of just back to campus with the rest of you. So a little bit about me. I've kind of always been interested in computers, right? Taking things apart, understanding how they work. Being an engineer, right? I'm sure I don't have to tell you guys that you're in third year. You're well aware of that. But yeah, so that's kind of how I'll try and break down this course, trying to give you understanding how things work, hopefully why they work. We can explore all the decisions and the fun trade-offs and all of that fun stuff. So a little bit of housekeeping. Ashfin Goel is your course coordinator, which means if there's any big structural things of the course, you go to him. Hopefully you won't need to go to him. Like you can just learn everything, but he's the one that is setting all the kind of evaluation stuff. So you'll find the overall course website at that URL, which is where you'll get the labs from and all that. I'll talk about the labs a bit later. They also have a piazza for discussion for everyone, but we're going to hopefully do something a little better than that. Because I've used piazza before. It's okay, but students don't super like it. So the course website for you, Lucky Bunch, is just this. You can use elfson.com if you don't want to log in to Corkus. I haven't used Corkus. Everyone has actually used Corkus. Do people like Corkus? It's fine. Okay, because the other places I was at, whatever online stuff they had, was terrible and they refused to use it. But if you don't want to log in to Corkus, that's the URL. I'll also try and upload stuff to Corkus, just so everything's there, although my course listings disappeared. So I don't know what's up with that. I'm sure I'll find someone to email. So a little bit about the lectures, right? We're back in person for the first time in a long time, which is nice. Well, or kind of back to a more normal campus. So at any time during the lectures, right, feel free to raise your hands. You can just interrupt me if you want as long as it's, you know, you're not like yelling and disgust at me. And if anything's unclear, right, even if you'd want to just like really look confused like that, you know, even that helps. And coming to class, right, it's kind of important for both you and me so I can see how you react.   So hopefully you can come to course or come to class and make it, hopefully I'll do my best to make it kind of as interactive as possible, have little demos. We can play with code. We can break stuff. We can figure out why we broke it and kind of what's going on under the hood, right? So you kind of hopefully get out what you put in. Right, it's just more fun and also kind of keeps you honest, at least when I was an undergrad, right, from Crass Nation was a real thing. And forcing myself to even come to lectures just helped with that. But if you get sick, right, you don't feel like anything. I guess this is a 9am class. So if you don't feel like waking up or your commute is super long, then I'm going to live stream everything just on YouTube, just so if you don't feel comfortable going to class for whatever reason that day or, you know, hopefully you're tired, I applaud. Okay. So hopefully this is live right now. The camera angle is a bit terrible. So hopefully I can fix that so you're not like looking up at me. But that's kind of a later problem. So this should be streamed on YouTube. So should be fine, right? It'll have VODs. So you can use that before I use Twitch. But then there's like two platforms I had to upload videos on Twitch. So I mean, if you want, I can stream on Twitch too, but it doesn't seem to matter. It's probably easier if just everything's there and I don't even have to touch anything and the VODs are there. So that's a change. And yeah, the other fun thing. So discussions will be interactive on Discord. I used this before. People like it. Hopefully people like it here. Although this doesn't get any applause YouTube does. So anyways, okay. All right. One. All right. So I tried this before. I don't exactly know how I want to organize it with two sections. I don't know if you, you know, this section got up at 9 a.m. So clearly we have more grit than the other one maybe. So I'll do that there and just be on Discord. Plus I find it helps students kind of organize themselves.  Sometimes, you know, you can answer questions immediately. It's better than I find it's better than Piazza where you just kind of throw things in and then maybe someone answers your question like an hour later. Discord, you pretty much get your answers immediately. So I'll also set office hours. They'll mostly be by appointment. I'm generally pretty flexible, but also it'll kind of be offset by me being on Discord all the time. Probably in actually answering your questions. But I'll set office hours. I'll probably put on a little pull on Discord or something because trying to pull the class and figuring it out what best time works for everyone is pretty much impossible since everyone's schedules are kind of, you know, it's an engineering schedule. So it's kind of a disaster. But of course, right. A, office hours or anything will be streamed or recorded, unfortunately. Right. It's a resource just for you guys to ask me because otherwise everything is just kind of freely available so you get some benefit. So instead of a midterm, there's going to be three quizzes. The quizzes are online. The first one is September 29th. They seem to all be at 8 p.m. So yep. I would assume so. There's partial marks. I think it'll be kind of open. Yeah, we'll see that when we get there. We'll have practice to go ahead and make sure you're prepared for that because the first one's at kind of the end of the month, which is probably going to come up sooner than we think. And then there's also going to be six labs. So totaling 30%. The first one, I guess, is released tomorrow. You have two weeks for all the labs. You should not need two weeks for the first one. Yeah. You have an old version. Yeah. So if I fix these, so if in your slides, right, there's all my slides are versions. So if you go to the front and it's not 1.0.4, you have an old version. So you probably have an old version. So everything's right. We'll follow some good software engineering practices. So even the slides are versions. So you can go ahead, check the website, see what the newest one is. So yeah, these are the breakdown of all the labs. Some build on the other ones. So the lab three builds on lab two, lab five builds on lab four. I guess just as a curiosity, has everyone even used threads before? Few? Like 20% of the class? Okay. So I guess these headings mean nothing to you now. But you will learn what they are and kind of how to do them. And yeah, there's going to be a web server lab and lab five builds on lab four. And then of course, there's a 40% final, which is, you know, we don't have a date for that yet, but the university will give us one. So I have to say something about academic honesty. I think it's in my contract. So you can so you can study together, right? You can work together. You but you can't do your labs and quizzes together. They're fairly big and calm. Well, they're fairly big and have lots of freedom in these labs. So it's like super obvious if you cheat off each other, trying to be smart and rename and variable names isn't very good, right? I had friends that tried that. It's like, it's probably one of the lamest things you can do kind of hurts everyone involved, right? Because you'll be assuming you're in computer, you'll be writing software. Eventually this course is kind of one of those big foundational courses that if you write any software, even if you don't care about the operating system, right, your application, whatever you write is going to use it and actually understanding the operating system and what's going on with that is the only way you can actually optimize your application. So if you write any software, knowing this stuff is all good because otherwise, right, you won't have a single clue on how to optimize it. You always have to go for the layer below and any software you write, the operating system is the layer below. So of course it won't be tolerated, blah, blah, blah. I think the University of Toronto has like public discipline hearings which are kind of fun to read. So you can see how long people get suspended for and like their degree taken away and stuff. So if you want some fun reading, you can do that. I had some fun doing that. So they seem to take it really seriously, so probably don't do that. So there's a few textbooks, right? They only complement the lectures. You don't have to go out and buy them. Everything should be covered in the lectures. All the examples and stuff, right, will be doing, right?  But these are the textbooks anyways if you want some additional material, right? There's modern operating systems, which I built, which you would have to buy. There's operating systems 3D pieces which has PDFs free on their website and all these are hyperlinks if you get the slides. And if you're kind of rusty on C, there's of course the C programming language book because everything we'll be doing is in C. But again, right? I'm new. Please provide feedback. So I want you to get the most out of the course. I don't want to just like sit up here and just talk into the void. That's really boring for me. That's really boring for you. No one wants that. So hopefully we can take advantage and write. I'm new here, so I don't know any better if you want me to switch anything or have any suggestions, right? You don't have to wait for coursey vows or anything like that. You can just come talk to me, right? I'm on a reduced teaching load now, so I even have more time. So if you just want to come to my office and chat, that's fine too. Eventually, I'll eventually I'll even have an espresso machine if you want free coffee, but I have to wait for my move to happen. So not yet, but coming soon. And yeah, so hopefully we can make this course really good because I find all this content really, really interesting and hopefully you do too. So let's go on to this quote I like that pretty much sums up the course and computer science in general. So all problems in computer science can be solved by another level of indirection. And that is what an operating system is at in the finest or the most grain terms you can think of, right? Operating systems are just another level of indirection. So they sit between applications and the hardware. So your application instead of, you know, dealing with the hardware directly would go ahead and instead, you know, go through a lay of indirection, talk to the operating system and the operating system talks to the hardware. That way you don't have to write your application from scratch every time, you know, Nvidia releases a new class of video card each time there's a new CPU, so on and so forth, right? You just let the operating system deal with it. Only they interact with the hardware. You don't have to care about it. And then your application runs on all sorts of hardware, right? Kind of at the very core idea of it. So and its role is just to manage and coordinate the resources, right? So and then I guess, yeah, what is an operating system, right? Could be Windows, Mac, Linux, everyone probably has their own one they use. And then that's pretty clear that they're all very different. But when you get into like Ubuntu versus Android, they're considered different operating systems or most people would consider them different operating systems, right? But under the hood, they both use the Linux kernel, which we're going to kind of explore in this class, which is kind of one of the big foundational pieces of the operating system. But both Android and Ubuntu run very different applications. And that's kind of why people consider them different operating systems, right? Sometimes the line isn't super clear. Like for desktop applications, right? If you have just like a little console application you want to run, you could run it on your phone or your computer and it would behave pretty much exactly the same.  They use GUI applications. So you'd consider them different operating systems. So the different stairs, they're kind of display manager and their APIs they use, right? Linux uses Wayland or, you know, older Linux uses X11 and Android uses something called Surface Flanger to actually, you know, show the window on the screen. It gets even more confusing when you go kind of in the Apple world, because really what's the difference between iOS and iPadOS? Are they considered different operating systems? Not really, but they like to market them as different operating systems, but it's just kind of how big the screen is. Otherwise, they're pretty much exactly the same. So the line kind of gets even more blurry when you get into the marketing speak. But the core, no matter what operating system it is, they just allow you to run more than one application. That's kind of their primary job, right? Without operating system. What happens when you press power on on your machine is your CPU just goes and starts executing code blindly at a fixed address, which if you're doing embedded work or just have a single application, maybe you can put your application at that fixed address. So when you turn on your computer, it just runs that application. So that's okay for an embedded system. But for, you know, your computer, that's probably not a great thing. So and also, it kind of has the problem we discussed before, where if the hardware changes, right, you would have to rewrite your application and no one wants to do that, right? If you've embedded thing that you just kind of write your application once for, you know the hardware, you kind of ship away and you never see it again, that's fine. But for anything more complex than that, you probably need a operating system.  We might go into the boot process later, it's a bit more complicated than that. That's like a gross oversimplification. But at the core of it, that's what happens. So the first abstraction in this course is a process. So you can kind of think of it like a virtual CPU, right? Each process contains a set of registers, including a program counter, which you've seen, and, you know, you've done some assembly before, you kind of understand how that all works. So your operating system keeps track on a per application level, its own set of registers, including a program counter.  So when you start a process, the process itself, like the executable file, will go ahead and tell the operating system where to start executing code, because your executable is one part of it, it's just a bunch of program code. So part of the file format that we'll kind of see just tells it where to start executing. So we already can kind of figure out some tasks an operating system needs to do, and that we'll be learning about. So it needs to keep track, you know, keep track of a set of registers for each process. Again, that could be like your web browser versus your office program versus Discord versus whatever, right? And then you also have to switch between different processes, right? Even if you have only one CPU in your system, which no systems like that really exist today. But even if you only had one CPU, you have to kind of manage your time, when do you actually execute one versus when you execute the other. If you have a multi CPU system, right, which application runs on which core? Should I move them? How many cores does it run on? Right, it gets kind of more complicated. And then yeah, you have to decide when to switch. So do I let the web browser to sit there executing endlessly for, you know, forever? Or do I switch interrupt it and kind of let something else execute? So these are all problems we will have to solve in this course. Yep. This slide? Yeah. Yeah. But so this slide is actually a view of memory. But yeah. So yeah, so you know, even on one CPU, your operating system will kind of fool you that multiple things are running at the same time. So go ahead, execute Firefox for, you know, like one millisecond, then switch, execute Discord for one millisecond, and then each makes progress before you can actually perceive it. And it looks like multiple things are running at the same time. So that's kind of how an operating system at a very high level deals with managing the CPU. And then the next thing is memory. So if you write if you have a single application on a single board, you can use all the memory, it doesn't matter, you don't have to manage anything. When you have multiple applications using memory, it becomes a bit more difficult. One like super naive solution is just, you know, if I have eight gigs of RAM, I can just, you know, divide it up. So I'll give Firefox, you know, four gigs, I'll give LibreOffice two in the operating system to, although right, many of us probably open many, many tabs. So four gigs of RAM probably isn't good enough. So but this is one thing you could do. But the huge disadvantage of this is as soon as you set it, right, you can't change it anymore. So Firefox wants to use if you don't even have LibreOffice open, and Firefox wants to use six gigs of RAM, if you kind of have this fixed view of memory, you can't change anything. And then if you want to use another application, right, you'd have to section off another piece of RAM, make Firefox smaller, change LibreOffice, do something, it's just super, super inflexible and not a good solution. So we reach to virtualization. So what that does is it fools something into thinking it has all the resources. So we play a trick on, you know, LibreOffice, we tell it, it has the entire range of memory, so it can access any byte it wants to, and then the operating system has to deal with managing that. And then, you know, Firefox would have its own view of memory, right? So it would think it has all the memory, and it can use every byte, and then the operating system has to deal with that. But the nice thing about this is, you know, that start address for both Firefox and LibreOffice can actually be the same address, right? They can both think that's address 1000, for example, and access it and then the operating system will actually manage everything under the hood. So what does the operating system have to do if, you know, there's virtual memory and each one thinks it has its own unique addresses and they, you know, shouldn't be able to read each other's memory and they should be separated and all that. Well, if you're the operating system, you have to map a virtual memory address to a physical memory address. So, you know, if Firefox thinks it's, you know, using address 1000 on your physical RAM, right, you can't change, you can't grow it, you can't do anything, your operating system probably would, you know, map address 1000 to address 2000 on physical RAM, which, right, it's physical, so you can't actually overlap that. And then for LibreOffice, right, its address 1000 could map to address, I don't know, 3000 or 4000, right, just a different address and then your operating system is going to have to manage that, right. How many addresses is it using? How much RAM is it using? How much, you know, am I running out of physical memory? And then I have to, you know, do something about it. And then that's an error, right, if you run out of physical memory, one of the things you can do, if you're the Linux kernel, there's a special process that runs called the out of memory killer. And the easiest way to free up memory is just to pick an application and destroy it. And then boom, you have memory back, right. So that's one solution you can do if you want, if you actually run out of memory. So this concept of virtualization is really powerful. People have been building on it and using it for more and more things, right. So it applies both the kind of processes and virtual memory, right. Processes kind of act as a virtual CPU. Each one thinks it has the whole CPU when really it might not be executing at any point in time. And the operating system gets to decide that. But you can also extend that to the entire machine. So you can have a virtual machine, right. So you have a single physical machine that can run multiple operating systems at once. Like, for example, right, this machine right here is a running Mac OS. But, you know, throughout the lectures, I'll be showing everything on Linux, right. So here's a virtual machine. So this is actually Linux running on top of on top of Mac OS in a virtual machine. And another thing we have to do is handle concurrency, which is really, really fun once we start introducing threads and multiple things happening at once, right. In terms of like the high level of looking at applications, right. We want multiple applications running at once, right. You don't want to just be able to use a web browser and that's it. That would be pretty lame. And you also want your applications to do multiple things at once, right.  You don't want your applications isolated either. You want them to be able to communicate and talk to each other and actually show you things on a screen, right. Your web browser, you want to see what web page you went to. Discord, you want to see, you know, whatever text is coming in, game, right. You want to actually see the game, probably hear it. And then to do that, right, you want, you want applications and libraries to communicate and kind of all work together and the offering system has to facilitate any communication between them. So yeah, as I was saying, right, completely isolated applications aren't useful if your application is completely isolated and can't talk to anything else, it will essentially just make your laptop or desktop hotter and not actually do anything, right. Even the simplest program that just prints hello world does some communication, right. It's printing, you know, it's sending hello world to the screen and you expect to see it. So there's something going on there that will kind of dispel in this course. But again, some more tasks for us to learn, right. If you're the offering system, you have to allow multiple applications or executions to run at once safely, right. So you don't want them to contend with each other. You don't want one application being able to affect another one.  Every time we write a buggy program and execute it, do you want your web browser to die? Probably not. Then another task for the operating systems to manage different kinds of communication. So they're called inter-process communication. So talking between processes can be anything from, you know, networking to, you know, just sending data back and forth, writing to a file, anything like that. And then, of course, when you want to share something, you have to have some permissions and security, right. You want to make sure that whatever applications are communicating together, it can't be intercepted by another one. And then the last piece of the puzzle is persistence. So for our basic operating system, we need some type of persistence, right. You want to be able to access data between boots. If when you turn off your computer and then turn it back on again, everything you've done is deleted and doesn't exist anymore, that's not very good. So you want to be able to persist data across boots and what does that is the file system and it specifies how to kind of organize, organize data on your storage medium, whatever it is, like a spinning rust, like those big hard drives that probably no one's really seen before or NVMe drives or SSDs or anything like that. It's just a bunch of bytes and you have to lay out things in a specific way to represent files and folders and everything like that and we'll see that towards the end of the course. But again if we're kind of, you know, listing everything an operating system needs to do, it also has to be able to store and retrieve data and kind of ensure that integrity of the data. So if you write, I don't know, solutions to your homework, to the disk, you don't want it to, you know, when you read it back later you don't want it to be different than when you actually saved it the first time.  So one of the kind of big abstractions is file descriptors, so they abstract both communication and persistence. So a file descriptors kind of, have people used file descriptors before? Not really. One person, alright. So has anyone written to a file before? Okay, so if you've written to a file and you've actually executed it on Linux or something like that or macOS, you've used file descriptors but there is a layer of abstraction that completely hit it from you. So we'll be learning about file descriptors in this class but basically all they are is just a number and then each process has, you know, a set of numbers that represent file descriptors that are just numbers that you can read bytes to and write bytes from. So it's like read some bytes from file descriptor zero, write some bytes to file descriptor one and then because it's abstracted like that those file descriptors can actually represent anything. It could be, you could actually be writing those bytes to a file. You could be writing them to a network. You could be doing all, writing them to whatever and the offering system is going to manage that. So yeah. So and that's kind of one of the big abstractions that you won't be able to get away from. And then if you're looking at the kernel stuff, right? The core part of the offering system that actually interacts with the hardware. Unsurprisingly, most of that code, right? If you open up Linux on GitHub or something like that, you'll find that most of the code doesn't actually do what we described before all that management and stuff. It's actually just device drivers. So it's stuff that talks directly to the hardware. So they're responsible for implementing the abstractions onto physical hardware. It's really, really boring. It involves just reading manufacturer specifications and then finding out that they're wrong and then trying to work around them, right? There's generally lots of inconsistencies between the documentation and reality. So this is like an actual comment from the Linux source tree. So there were two versions of a BIOS, which is kind of the first piece of software that executes when you turn on your computer. So the offering system, you know, has to kind of initialize it and deal with it. So there's two models of a Dell laptop here that were released pretty close together. One's bad and one's good. So the joke here is that this is the technique they use to write BIOS code instead of understanding what it should do, right? They just wrote some code, checked if it compiled. If it did compile, they wrote some more code. As soon as it compiled, they checked if it booted Windows 98, which is how old this it was. Then if it didn't, they'd go back, write some more code. And then as soon as it booted Windows 98, they'd ship it. And then so whatever bugs they had, right? No one writes perfect software, especially if you're doing a technique like this, where you just kind of hacking at it until it eventually works and then shipping it and then never seeing it again, right?  And then if you're writing the code that has to interact with someone that wrote software like that, you're going to have a bad time because you're going to have to work around it. So luckily in this course, we'll stay away from device drivers and all that. But if you really like kernel development, I'm just giving you a little bit of fair warning ahead of time that sometimes it can be very, very frustrating. All right. And to kind of motivate the rest of the class and to see how simple things actually are. Yep. Oh, you're good. Okay. So everyone can kind of read Hex, right? Okay. All right. So everyone can read Hex. So I'll dispel the magic of computers. So everything in computers is just a number. No matter what it is, it's just a number. And it's how you interpret it. So here are some raw bytes. So each number here right between the spaces is just one byte. And there are 168 of them here. And this is actually a program. So who is a who can tell me what this program does print and why does it print hello world? It says so at top. That's a very good answer. So right, which this seems kind of weird that it prints hello world. Because if we actually, you know, wrote a hello world and compiled it, right, even our text file would probably be bigger than this, right? Depending on how much white space you use. And then when you compile it, right, it's going to be like, it's going to be like three kilobytes or something like that, which is, you know, several thousand bytes, which is a lot more than 128. So we'll also kind of be dispelling all the fun magic that goes on with, you know, your compilers and other libraries and stuff.  Let's go ahead and see. So I have two main files. All right. So I have this file called 128 byte executable. This is just running Linux just on, you know, this. So it's running ARM, which you might have some assembly experience with. But you can see here, this column says what size it is. It is indeed a hundred and sixty eight bytes. And if I, you know, do a hex dump of it, we'll get some insight into it. But I can see that the bytes are the same that were on the slide. So if we go ahead, we see all the bytes. And, you know, if it's within an ASCII range, right, so everything's just a number. All your strings are just numbers. And then you interpret them as characters. So if you go ahead and look at the kind of right side here, you can see the contents of the file when you convert it to characters. So if it can't represent it, it just puts a period. So you can see the first three letters here are elf. That could be related to my last name. It could be not. You have no idea. But it's kind of weird that that's there.  And then at the end, it kind of says hello world. So there's at least hello world somewhere in it. And if we go ahead and execute it, right, we actually get hello world, which is, you know, way, way smaller than if we wrote it and see. So that's one thing we have to look forward to. Because next time we'll go ahead, we'll explain every byte of this because, you know, part of the goal of the operating system, it has to take all those bytes, do something with them, execute them, right, that's kind of the smallest example of a program. And, you know, no one showed you that before, even though it's actually really, really simple, right, even if each byte does something crazy, it's only 168 of them. So it's not actually that complicated. We can kind of tell or raise these bytes what they do. And most of them zero. So it's probably actually not doing anything important. So, you know, just in summary, we get to end a bit early. There's three major concepts in this course, right, you'll learn how the following applies to offering systems, virtualization, concurrency and persistence. And with that, just remember, I'm pulling for you, we're all in this together.


Hi, I'm Frédéric Desbiens, Program Manager for IoT and Edge Computing at the Eclipse Foundation. Welcome to Game of Protocols, the presentation where protocols will fight for your hearts and minds. Alright, so what do we have on our play today? Really simply three things. First, I will explain to you why you need to pick a protocol. This seems trivial, but some people think there's a one-size-fits-all approach in the market, and I would just want to show that that's really not the case. Then we'll review a few established players in the market, so options that are mature, that you can use right away, and that are widely supported. And then we'll have a glimpse at a few emerging challengers, so protocols that are maybe a bit less mature, but show a great deal of promise for the future. Alright, so let's get this show started. So why exactly do you need to choose? I think the best way to illustrate this is with quotes from real developers, real people that I met at conferences, or that I interacted with over the internet. One common thing that I will see is, well, I don't need to choose. Ajax Foundry or with whatever product you want to put in there, okay, fill the blank. That product has multiple local supports, so I don't need to choose one. And okay, yes, maybe at the technical level it's true, but the problem with that approach is that then you don't take into account the specific use case you're having. Or just picking random software stacks and parts even for your project, and you're not getting the best fit for your specific use case. Then the second option would be something around the lines of, oh, REST is simple, I can do everything with it, it's widely supported, so why would I need anything else? Yeah, but the problem is that yes, REST is widely supported, but it's not necessarily tailored for the world of edge computing or even IoT. If you have a tiny, tiny MCU and you need to make the battery last for five years or more, then it's probably not the best option, even if it's simple to use and widespread in its adoption. And finally, another thing that I heard a lot is, well, plain TCP is good enough for me. I can work with that, it's literally everywhere, and I can use straight UDP maybe if TCP is a no go for my project. And okay, if you want to go that route, it's up to you, but the problem with that approach is that essentially you're operating at a very low level, and this has consequences. So the reason why you need the right protocol for the right job is really about three things. First, okay, your choice of protocol really will impact many, many, many things about your project. And that's really important, okay, the performance, the throughput, okay, depending on the protocol you will use and the specific amount of data you need to shuffle and the conditions of the network, you know, they have better choices than others. And then there's the battery life in IoT, that's a fundamental concern, the number one constraint you need to think about. Developer productivity is another thing, I mean, maybe plain TCP is, you know, an option that you will get nearly everywhere, or plain UDP, but then you need to parse all of those packets on your own, et cetera, et cetera, and what about security, and what about encryption, and what, I mean, you are using the lowest common denominator if you do that, and you won't be productive. And then there's the whole question of security. And implementing security on your own, you know, is one of the biggest, the biggest mistakes you could do.  So why not use, you know, measure solutions that will integrate it for you? Okay, then when we think about REST, the thing is, as I mentioned, HTTP as a protocol, it's fine and REST as an approach is fine, but it's lacking many of the features that you will see IoT specific protocols got, quality of service, reliability, and there are many, many others. So assume that each and every feature that the protocols I will talk about today or, well, not will, I'm actually talking about today about those protocols. So all of the features they've got, most of the time, HTTP won't have them, okay. And then there's the whole question, once again, of productivity, low level protocols will slow you down. I need to re-emphasize that point, right? Especially if you're working on using C, you know, working on the Zephyr application or something like that, writing C code, you really want to write all of those lines of code to allocate memory, deallocate memory, you know, create buffers, parse payloads and that kind of stuff.  And we don't want you to do that. We want really to focus on your specific use case, which means that using a higher level protocol is a good option. All right. So now let's review our main contenders for today's game of protocols, Co-App, DDS, MQTT and Lightweight M2M, okay. And we'll review them in alphabetical order, although on my slide here they are not, okay. And this is to emphasize that I have no favorite there. It's really about picking the right protocol for the job. Okay. First, as a reminder, you know, the Zephyr RTOS, and I know that many of you at this conference really care about this, the Zephyr RTOS really has built-in support for three of my four main contenders. So I put links here, so if you download the presentation, you can access directly the samples for Co-App, Lightweight M2M and MQTT. And as you can see on diagram, this is really an integral part of, you know, the Zephyr RTOS. And this distinguishes really Zephyr from competing options in the RTOS space in the sense that you have all of that as open source as part of the main tree, you know. And those clients for the various protocols are, you know, high quality and tested alongside with the OS, which is not something that you will find in some competing options. Okay. Now, going forward, so what is the Constraint Application Protocol or Co-App? Okay. So Co-App is a protocol really that has been engineered from the ground up to really target constraint devices. Okay. It's managed by the Internet Engineering Task Force, IETF, and documented in a specific RFC, and then there's a bunch of other RFCs that, you know, provide additional features on the top of that. Really the obsession of the designers of Co-App was to have a minimal overhead, okay. Co-App can run on the top of most devices that can support UDP or will use protocols that are roughly equivalent in terms of resource usage as UDP. The thing with Co-App is that really, you know, it's meant to run over the Internet, okay. So you can use it to integrate devices that are on the same network, but you can integrate those devices to general nodes over the Internet, or even you can join devices that live on distant constraint networks, and those networks would be bridged then by the public Internet. Okay. So all of those deployment models are possible with Co-App. Co-App intentionally has been designed to be really, really, really close to HTTP. So this is a request and response protocol, and it follows the REST models. So the get, put, post, and delete verbs are used. It's using URIs, response codes, MIME types. So if you're familiar with HTTP, Co-App is fairly easy to pick up. And one thing that has been adjusted is strong support for Co-App for multicast because more often than not, you will want to broadcast a bunch of data to a number of nodes. All right. So at a deeper level, what are Co-App's features? Everything that Co-App does is asynchronous. Okay. So it's really, you send message and execution continues right away. Low overhead because it's on the top of UDP is another big concern. And even in the design of the protocol, the headers will typically be about four-byte long only. Okay. So that's fairly compact when you compare to many other protocols that are used in the data center. All of the payloads and, you know, the messages themselves are really simple to parse because they are exactly, they are exactly replicating what you will find in HTTP. And there are many HTTP-like techniques that you can use with Co-App. Okay. So URI, content type support, that kind of stuff, proxy caching, really all of that is accessible when you work with Co-App. So very briefly, let's have a look at the stack for Co-App. And an interesting thing is that really Co-App is well supported over Bluetooth and Six Low Pan as is lightweight M2M as we will see a bit later. And the fact is Co-App in its approach is also relying on UDP and something called DTLS, which is you can see it as a specialized version of TLS to go along with it, but it's a bit simpler and a bit lighter on resources. Anyway, so essentially the whole point of Co-App, as you can see in the stack, is really to send messages over this request and response pattern. All right. If you have to pick a Co-App stack, obviously on device, if you work with Zephyr, you have built-in support and there are many small libraries written in C that you can leverage for that. But on the server side, especially if you need to write a fairly ambitious application that leverages Co-App, the most popular option, at least in my perspective that's currently in the market, is Eclipse Californium. And Eclipse Californium really has a whole bunch of additional features over simple Co-App implementations that you will find elsewhere. For example, it implements Observe and Notify. So by default, Co-App is a request and response, but you can make it, you know, you can use it in a kind of publish and subscribe model by using the Observe and Notify features of Co-App. Californium also supports block-wise transfers. It implements the latest version of DTLS. And as even experimental implementations for Co-App over TCP, so, you know, if you want to benefit of some of the advantages of TCP, then you will be able to leverage them. And there's something called OS Core, so a kind of security model for RESTful environments and Co-App as experimental support for that standard as well. Also Co-App will enable you to bridge Co-App and HTTP connections through cross-proxies. And it comes in the case of Californium with a scalable web resource framework and you even have a kind of runtime container for JavaScript mashups. And you can leverage an OSGI wrapper if you are working, you know, on a managed server that will support that. So really, Californium is a very major project that we've got at the Eclipse Foundation. It's certainly well maintained and has tons of adapters in the market. And I invite you to have a look if you are interested in working with Co-App. And Californium is both a client and a server implementation. So if you need to access to Co-App resources from a Java application, then you can also leverage Californium. OK, our next contender now for your hearts and minds is Data Distribution Service or DDS. OK, DDS is a different animal than from Co-App. Really, it's a publish and subscribe protocol optimized from machine to machine communication. And it's really focused on the decoupling of applications. OK, so the really fun thing about DDS is that any node can be a publisher, subscriber, or both simultaneously. And the reason why is that is that there's no central broker on anything like that in DDS.  DDS is already widely adopted in specific verticals. You see it a lot in aerospace, defense, air traffic control, robotics. And DDS is a specification of the DDS Foundation, which is one of the foundations that are related to the Object Management Group or OMG. And OMG, they are the godfathers of UML and many other interesting technologies if you are less familiar with them. So there's a formal spec for DDS. And you can certify your projects and products against it. OK, so what are the main features of DDS? DDS at its core has this concept of a data space, OK, that will enable you to decouple applications from one another. So this decoupling is spatial so the nodes can be on any network anywhere and temporal in the sense that the communication is not happening necessarily in real time. As I mentioned, DDS is completely decentralized, which means that there's no single point of failure. So maybe that's an interesting feature for your use case. And DDS supports a quality of service policies, OK, and those policies, they express specific constraints about the temporal and about the time and availability of the data, OK. And that's really, really something nice about it. On the top of that, DDS has mechanisms for built-in dynamic discovery, OK. So essentially out of the box, DDS nodes can discover other nodes around them and establish communication with them. So this is our protocol stack for DDS. And in this case, there's an interesting distinction. DDS can run over out of the box TCP or UDP, and it has a kind of wire protocol for interoperability. That's quite a mouthful. So DDSI-RTPS is the wire protocol for interoperability. And then on the top of that, you have DCPS, which is literally the published subscribe model of DDS. So those two things are documented and there are distinct specifications around them. OK, now, if you want an implementation of DDS, one of the leading ones is certainly Eclipse Cyclone DDS. So this is a pure C implementation of the protocol, and it's got really a tiny, tiny set of runtime dependencies. So typically, it will compile very well in a variety of environments. It's really compact, so it will fit if you strip a few features in as little as about half a megabyte of memory at runtime. And out of the box, it supports multiple platforms, and it's tested over Linux, Mac OS, and Windows, but then many people have run it in a variety of environments. The great thing about Cyclone DDS is that it's now a tier one middleware in the ROS2 operating system. So the robot operating system, very popular, as the name suggests in robotics, has Cyclone DDS as a first class citizen there. So it's certainly an interesting option if you are invested in that particular ecosystem. OK, continuing now with container number three, lightweight M2M. So what is it exactly? So in this case, lightweight M2M has really a tight focus on lightweight and low-power devices, OK? And lightweight M2M requires co-op. So it runs on the top of co-op, but as you will see, it brings a whole lot of value-added features on the top of it, OK? One interesting twist of lightweight M2M is that it defines an extensible resource and data model, OK? So you can really out of the box work with what's there, but you can extend it in a standard way so that even if, you know, let's say you produce a device and it supports lightweight M2M and people don't necessarily have the documentation for that or they are not necessarily familiar with the specific resources and data that you are exposing, then there are standard ways to discover that using lightweight M2M and then to leverage that. So this extensibility makes it really attractive. The specification for lightweight M2M is owned by a nonprofit called OMA Speckworks. And you've got the link to their website on the slide. OK, so what's so interesting about lightweight M2M? Lightweight M2M really, as you will see, really focuses on the management of devices. So it offers you, for example, bootstrapping mechanisms. So if you, for example, you produce devices and you ship them from your factory with specific keys and encryption certificates, that kind of stuff, the thing is your customers then can deploy a bootstrap server where your devices out of the box will connect to that bootstrap server. And after that, they will be able to retrieve their production certificates and encryption from parameters from literally the bootstrap server. So this means any device that you ship from your factory to your customer doesn't need to ship specifically with certificates that belong to the certificate authority of your customer. You just bundle your own, and the bootstrap server will make the substitution in your customer's environment. And this is really a powerful mechanism in lightweight M2M. Lightweight M2M will take care of device configuration, fault management, configuration of devices, control, reporting. But one interesting thing that it does is to support firmware updates. So lightweight M2M supporting device connected to a server. The server can start the process of updating the firmware. The device, typically, this involves to pass a specific URL to the device so that it will know from where to download the new firmware. The device will do this and automatically deploy the new firmware, reboot, and et cetera, et cetera. So all of that is really well-defined in lightweight M2M, and it's an interesting option if this is the kind of scenario you want to implement in your device. So the lightweight M2M protocol stack is interesting in the sense that it will support TCP and UDP with or without the TLS, but it will also run over SMS. So you can send SMS messages over a cellular network, and the lightweight M2M stack will be able to understand that as well. And obviously, the diagram here doesn't repeat everything about co-app, but really you see that lightweight M2M runs on the top of co-app. And then there's the principle that you have specific objects in the extensible data model that are leveraged by your application. So if you want to work with lightweight M2M, there are projects at the Eclipse Foundation for that. Eclipse Leshan and Eclipse Wakama. So Leshan is not a complete server, but rather a library for implementing lightweight M2M clients and servers. It's very mature and well-supported. It's very simple, so it's not using any frameworks of its own, and it's using really few dependencies. And it provides you a basic web UI to discover and test the devices. And really, you just build the code using Maven install, so it's very straightforward to work. And it's leveraging Eclipse Californium under the hood. So really, we are drinking our own champagne here, for sure. Then on the device side, obviously, there is built-in support for lightweight M2M in Zephyr. But if you are in another type of environment, then Eclipse Wakama is a C-client implementation, fairly portable, I would say, that many people have adopted in the market.  And MQTT previously, earlier in its life, was an acronym. It stood for MQ telemetry transport. And MQ was a reference at the time since it came from IBM. So maybe you heard about MQ series or WebSphere MQ from IBM. So the MQ reference is there, and MQ stands for message queuing. Anyway, nowadays, MQTT is the name. It's not an acronym anymore. And really, it's a protocol that targets constrained devices, but specifically constrained devices that operate over low bandwidth networks. So it runs over TCP, but there's a flavor, so to speak, of MQTT, MQTTSN. And SN stands for sensor network that runs over UDP. But MQTTSN is less mature, let's say, than plain MQTT. And really, the focus of MQTT, when it was created at IBM and with the help of Eurotec, one of our members in Eclipse IoT, is really that it was targeting SCADA types of applications. So industrial types of applications that need to control machines or get data out of machines and that kind of stuff. It's really using a publish and subscribe architecture and is not meant for durable and persistent messages. So you don't run your whole business with, let's say, banking transactions over MQTT, but you shuffle data that eventually will come into those business applications. And MQTT is a specification owned by OASIS. All right, so what are the features of MQTT? MQTT defines three levels, essentially, of quality of service. At most once, OK, so if your message is ever delivered, there will only be a single copy delivered, at least once, where you have at least the guarantee that one message will be delivered, but there could be multiple copies and exactly once. So you have a guarantee that each message will be delivered. It's guaranteed and only a single copy will be delivered. Obviously, as you go from 0 to 1 to 2, the throughput falls because the servers and clients are exchanging more messages in order to implement the quality of service. A nice thing about MQTT is that it implements persistent sessions. So essentially, if you don't use persistent sessions, every time that the client connects, it must specify, OK, I want to subscribe to this topic and that topic and that topic, OK? Persistent sessions means that a client automatically will be reconnected to the same topics all the time. So this simplifies your code. MQTT has also a feature for what is called retained messengers. Normally, by default, you send a message, and whoever is online as a subscriber will get the message at that time, OK? And then the message is gone. But MQTT has a feature where essentially the last message sent on a topic will be retained so that if there were clients that were offline, subscribers that were offline, they will get that message first thing when they will establish their connection. There's also a notion in MQTT of last will and testament. So essentially, if a client or subscriber is disconnected violently from the broker, then essentially, it will be able to send a last will to a predefined message that will announce to the rest of the network that that specific device is gone. And then there's also this notion of keep alive on MQTT. So even though it's running over TCP, it will keep the connection open for you, which is typically more something you will find in UDP. So this is the MQTT protocol stack. And here it's fairly standard. So MQTT, the plain version, so to speak, runs over TCP. And you've got MQTTSN on the top of UDP. OK, so now we have our four core tenders. So which one should you pick? Well, before I say that, we've got implementations. I got ahead of myself there. So we've got implementations for MQTT, obviously, at the Eclipse Foundation. Eclipse Paho is a collection of MQTT clients in several languages and they target multiple platforms. And all of those clients have a wide assortment of features, automatic reconnect, offline buffering, et cetera, et cetera, even high availability in some of them. And it can be either blocking or non-blocking in some cases. So depending on your style of programming and the environment that you are targeting, this is certainly a trend. And then we've got the very popular mosquito broker. It's part already of most Linux distributions. And mosquito is written in C and is certainly a very popular option as far as MQTT brokers are concerned. Okay, now, before we get to the choice, I must also cover very briefly a few emerging challenges. And here we will cover specifically SPAplog and Zeno. So one of the great things about MQTT is that it doesn't say anything about the payloads. So it's fantastic because you've got flexibility. One of the bad things about MQTT is that it doesn't say anything about the payloads. So you have, when you deploy an MQTT-compatible solution, let's say you buy robots from one supplier, and then you buy a software stack from Anautur, and then an Anautur machine from a third supplier, they all speak MQTT. But you will need, at a minimum, to configure them, to point them to the right topic, or to parse the payloads, or to massage the payloads in a specific format, et cetera, et cetera. And all of that is error-prone, it's time-consuming, it's frustrating. So a few bright people at CirrusLink and Inductive Automation two Eclipse members came together and with other community members to start what we call the Eclipse SPAplog working group. So SPAplog is both a specification at the Eclipse Foundation, and there is also an implementation in the Eclipse Tahu project. So what SPAplog is about, it's essentially about three things. First, it defines standard payloads, okay, standard payloads on the top of MQTT. Then it defines standard topic structures, and finally stateful session management. And all of that, okay, make it possible out of the box, okay, when you have devices that support SPAplog, they will be able to speak to each other out of the box without, well, with a minimum of configuration. And this is really a game changer. So as I mentioned, SPAplog is both a spec and an implementation, and all of that, both the spec and the implementation in Eclipse Tahu are completely open source. And this really solves a big problem in the market, really. So MQTT is fantastic, it's there to stay, but by running SPAplog on the top of MQTT, you can really get at the next level. And then we have an intriguing new kid on the block, which is called Eclipse Zeno. So Zeno is a protocol that comes from our efforts in edge computing. And really, it's a pop sub protocol that matches, you know, storage and queries and computations, you know, in a fabric. So the great thing about Zeno is that it unifies all of the data in the system, data in motion, data in use, data at rest, and even computations, okay? It's a unified model. And it blends the traditional pop sub primitives that you will see in MQTT and DDS, for example, but with, you know, the dimension of geographically distributed storage. So this makes it very attractive for edge computing because obviously in edge computing, you want to have the data and compute as close to the source of the data as possible, okay? And finally, Zeno has been highly optimized for low latency and high throughput. It's really the obsession of this team. So Zeno is available in a variety of flavors and they are working now on PicoZeno, which is a C implementation that should fit, you know, on most RTOSs. So it's still, you know, an emerging project in the sense that it's been around for a while, but they are working on many language bindings and stuff like that. But anyway, please have a look. I think that's certainly one of the most innovative projects that we've got at the Eclipse Foundation. So how would you pick any of those protocols really for your specific project? And there are really, there are three major things. There are many other things, but really if I want to boil this down to the fundamentals, you'll see them on this slide, okay? So first, there's your use case. Are you collecting data or controlling devices? That's really the fundamental question. If you are collecting data, then probably publish and subscribe protocol is the best. But then if you are controlling device, maybe request response protocol could be used. But then, you know, there are many, many other considerations there and sometimes maybe you will choose to use more than a single protocol in order to optimize the solution, okay? Then you need to think about your constraints really in picking. So your bandwidth, your battery, the compute power of whatever MCU you are using. You know, what are your constraints? Because some of those protocols will require a bit more resources than others. Some of them run just over TCP for the time being, so that's a bit more resource intensive since you need to maintain the connection, et cetera, et cetera. So there are many, many things to consider there, but you need to be aware of your constraints to make the pick correctly. And finally, there's the whole dimension of support. Does it support the hardware, the OS that you have? Can you procure sensors and devices in the market that already supports it and then your time to market for your wider solution is faster? And that's really an important dimension. And you need to take that in consideration because once again, what you care about is delivering the solution, not to write low-level code and solder components together in order to build your own sensors, right? All right, so as I said, there are utter factors to consider, but really those three are really the most important ones in my opinion. So now, I told you a lot about the protocols and the various implementations we have for them in the Eclipse IoT community. So what's the Eclipse IoT community? Well, essentially, it's 46 member organizations and now getting close to 375 contributors writing code in 45 open source projects and counting. Those numbers are never up to date. They always go up. And overall, when you consider all the projects we've got, that's roughly eight millions lines of code that you can leverage in order to deliver solutions. This is our memberships. So we have three strategic members, Bosch, EuroTech and Red Hat. So those are the ones setting the vision for our working group and really leading the others. But as you can see, we've got many, many members there and a shootout to the Linux Foundation. The Linux Foundation is a member of Eclipse IoT since essentially we're working together on promoting the Zephyr real-time operating system and trying to make sure that our components work well on Zephyr and at the same time that our members are aware of what Zephyr has to offer in the embedded space. And obviously, Linux is another big environment for us as well. So that's another place where we work together certainly. All right, so Michael, to you now that this presentation isn't really over, please join us. Please become a member of the Foundation and please become a contributor to our strategic open source IoT projects. You can contribute to any of the projects I described today right now. You can submit PRs and if you submit enough of them and they are high quality enough, you can become a contributor even without being an Eclipse member. But we would pretty much enjoy your support if your organization can join the Foundation. And especially in joining the Foundation, joining the Eclipse IoT working group would be the wise thing to do because this is where things happen in embedded and IoT at the Foundation. So at this point, the only thing left to say is a big thank you. Thank you for listening to me. And as I said before, I'm Frédéric Déviens, Program Manager for IoT and Edge Computing at the Eclipse Foundation. And you can reach me on Twitter as BlueberryCoder and please visit our website at iot.eclipse.org. Thank you.


Yeah, but I like fire hoses. You know, I've been in this situation before where I've had to learn a whole new language in a matter of weeks. So I do have some familiarity being in Shanahan's offense before and there's some carryover between the system. So I mean the fact that they already kind of got all their installs and they're going a little deeper now is a little tougher than like a day one install. But it's part of the job and you know, I'm embracing it. Yeah, there's a lot of timing routes in this offense and so a lot of throws, some of those outbreaking routes and other benders. You just got to learn these guys and that comes with time and with reps, just feeling them out, you know, from when they get in and out of their breaks, but it'll get there in time. Yeah, it's one of the reasons why I chose to come here. I love Ryan, I've known him for years and just have heard nothing but great stuff about this staff too. Even was with Logan in Cincinnati when he was a rookie and he's grown up in a lot of ways from when I last was with him. So it's a great room and as long as I can, you know, help this team win, I think we're in the right path. No, I mean, I'd heard of his name, but we had never met. You know, he was doing his thing coaching for all these years, but you know, to have another Trojan in the room is somewhat encouraging. I wouldn't call it nerve wracking. It's just a waiting period, maybe nerve wracking for my wife, just the unknown. But I mean, I've been not this late into camp, but I've been in a situation before where there's just unknowns and you're just kind of at the mercy of whoever, you know, is making decisions. But again, that comes with the territory and when your name's called, you've got to be ready to go. I've seen a lot more football, you know, even if I haven't been playing this whole time. Just being in the room with some great QB's here in their thought process coming up with plays, almost being a coach of sorts and helping them out. But then again, just the perspective that I have now from my first couple of years in the league is completely different just in terms of how I see the game and see defense. You know, it's not just learning a playbook now, it's applying this offense to what I already know in the grand scheme of things. So I think I've come a long way and I'm throwing the ball a lot better than I was even when I entered the league. Yeah, he's a clear leader of this team. The way he steps up is vocal in meetings and on the field, commanding guys, making sure everyone's on the same page. There's a reason why he's had so much success. It's just evident in the way he carries himself and how guys look up to him. So, you know, it's going to be fun again to learn from him and to help him in any way that I can. So what was I doing? Yeah, just training, strength training, conditioning and then throwing three, four days a week. Just kind of trying to put myself in that camp mode. It was a little hard to replicate the humidity in Southern California. But besides that, you know, throwing and getting all those reps in, you know, just ready for when that time came. Yeah, for now. Yeah, we got kids in school, so we're trying to navigate that world and where we put them. There's great schools here. So we'll figure that out when we get there. Not anything in particular. You can probably ask them about that. It's the fact that, you know, they know what I'm capable of and how I helped Josh in the last couple of years and just what I bring to an organization.


If you're looking for text to use for exploring about residential school in the Canadian classroom, this is more kind of, this one right here is probably appropriate up to, I would say like grade 3. And these ones right here, of course, this may be about grade 7, grade 8, grade 9, and this one would probably be more middle years. So some wonderful texts are Not My Girl by Christy Jordan Fenton and Margaret Pokiak Fenton. Another one, My Name Is Sapezza by Shirley Sterling, Very Short Read, Exploring Residential Schools, and A Stranger At Home, a true story by Christy Jordan Fenton and Margaret Pokiak Fenton.