I propose to take an example of a particular information system and to describe some aspects of how information is handled. The example is that of an industrial organization. Typically, an industrial organization manufactures and sells goods and it has generally the following broad functions that have been listed here. Which are these, manufacturing, which happens in plants or works, marketing, selling, then accounting and finance when you collect money. Material management because when you are manufacturing something, you are purchasing raw material from some other people and you have to manage the inventory of raw material and finished goods.  And finally, the corporate planning. Whether you should increase your manufacturing, reduce it based on demands, etc., etc. This is the strategy. Of all these, we will look at the inventory management problem. Most of you are familiar with the word inventory. Anybody here who does not know exactly what inventory is. Because industrial engineering and war people or such people will know that. Inventory is defined not, hypothetically is often defined as a cost, as a value, rupees. And it comes out of, let's take raw material and sub-assemblies which are needed by some plants for production. So, a material manager proactively procures material and sucks it. So, let's say you are manufacturing fans. And you have, let's say some coils or some rotor or blades which have to be ordered from sub-assembly providers. You have to keep them. Ideally, if you are going to produce 200 fans today, in the morning somebody should supply all the parts of those 200 fans and you should assemble and sell them. And actually sell them and dispatch them. But can this happen in reality? No, that fellow may not supply. So, you have people who are employed to produce fans but they have no raw material. Or you produce 200 fans today, 200 tomorrow, 200 day after tomorrow but nobody is picking them up. So, you have to store them. Every time you store either the finished goods or raw material it represents some cost. Because you have paid money but you are not able to exploit them. That is why a stores clerk who issues material against request and receives material from suppliers has to manage this inventory. And the cost of such stored material till it is used is actually the inventory. So, let's say I manufacture 200 pieces of equipment for which I buy say 500 different items from different resources and store them for different times. Then let's say at any point in time the average cost of all the items which are pending or stored is said 2 crore rupees. My inventory is said to be 2 crores. Why would I like to reduce the inventory? Obvious reasons. My 2 crore rupees are sunk there because I have already paid. And unless I recover money by selling the finished goods that money is blocked. The interest on 2 crore rupees plus the cost of the remises where I store this is all costing. I would like to minimize this inventory. Ideal inventory should be zero. It's called need to require basis. Just in time inventory as it says. As I require for manufacturing I should get it. This does not happen normally. Please note here the important point from an information system perspective is the stores clerk. Stores clerk is expected to get request for material. Get me 30 rotas today because I need them. Get me 2 coys for some equipment. Get me 20 fan belts. This request will come from production plant. The source clerk will issue those and record. Occasionally he will receive things which the supplier has supplied. So you will have to make those entries. That is the focus of the information system that we are talking about. But we are talking about this in the context of inventory control. Here is an example of a simple inventory control. The cost of inventory as I said comprises of price paid for the goods, storage costs, interest burden and cost of the procurement process. There is no free lunch. If I have to purchase let's say 500 fan belts then I have to ask 3 or 4 vendors. I have to write letters to them. My salary is being consumed. My time is being consumed. All that adds to procurement cost. Lead time for procurement. What is the average time by which I will get that thing? If the lead time is 10 days then I would order roughly when about 11 days of stock is there so that I don't waste my money in storing unnecessary things. But if I goof up my production will halt.  Here is a simple example of an inventory control. This is my home. The morning tea is made by using sugar from this small dabbha. Many of you would be familiar with such stuff. Typically every household in India has this. This is a small dabbha. The sugar will be consumed here in 3 days, 4 days, 5 days, 10 days depending upon the usage. So what happens when that event takes place?  I agree that the process generally you are all familiar with this. While doing so, every time she will notice how much sugar is there in this bigger dabbha. When that bigger dabbha also gets near exhaustion she will say, now the new sugar should come. Notice what she is doing in the process. She is deciding when to buy. She does not buy only when this sugar and this sugar both is exhausted because she knows about the lead time of the sugar purchase. What is the lead time? The lead time depends upon how lazy her husband or son is, how long he or she will take to go to the market and buy it. What is the availability of the sugar? What is the availability of cheap sugar in which shop? And she will know that she will have to spend 2-3 days. And she will ensure that last time she fills up this small dabbha she will say, that is her inventory count. This simple system by the way is called a two bin system of inventory control.  Last time the small bin is loaded more sugar is ordered to refill the larger bin. This point is called a reorder point. That means that is the point when you reorder a stock of inventory and you don't reorder small dabbha worth. You reorder 2 kgs, 3 kgs, whatever will go into that big dabbha. But at what point you reorder is important from an inventory perspective. You call it reorder point. At that point you reorder. How much you reorder? You don't reorder the full large dabbha because some sugar will be there always. So you reorder a certain quantity which is called reorder quantity. The reorder quantity would be ordered on a certain date and the beauty of the inventory system is by the time the supplier supplies the reordered quantity the small quantity will be sufficient for your normal production. That's the fundamental of this simple scheme. In any industrial organization there will be variations of this and several other models because it's a very complex problem. Imagine you have 10,000 items in the inventory. Each item has a different set of delays associated with supply dates. Different pricing is associated, different costs are associated. So it's a very complex problem. I'm just simplified. In this simplified mechanism what are the material related activities that happen? Please note we are trying to answer questions of what information is needed, why it is needed, when it is needed, by whom it is needed and we are making the store's clerk to be our focal point. The store's clerk is sitting in a store. He has multiple bins in which items are kept. The plants will keep sending requests saying give me 10 of these, 20 of these, 15 of these and they will receive internal material which is issued by the store's clerk. It is obvious that any time a reorder point is reached the material clause must send a shortage report to the material management system and the material management must order the reorder quantity for that item with the supplier and eventually the supplier will supply that material which will have to be accumulated in the store. So you will see the information that is required to flow, request loads have to flow here. The actual material will be issued here but the recording must be made here. The obligation must be such that shortage, whenever it happens a shortage report must go there, a purchase order must go there. Supply of new material which comes in must be accompanied by vouchers or purchased order date or whatever, whatever price, whatever. So this is the kind of information that needs to flow. How does store's clerk maintain information of all these things? This is what we are trying to see here. So the store's clerk must first verify the authenticity of the request, must locate and issue material and record data for each transaction, must check if balance is less than the order quantity, if so inform the material management and if there is any receipt of material because the previous order's clerk verify and record supply particulars and send information to material management and to account saying I have received this. Typically he would use a laser in a paper-based system, one page per item in the laser. The top part of the page will have overall information about the item. Let's say part code so and so, it's a small fan belt, its storage location has been number so and so in thousand bits that I have. The opening balance at the beginning of the year was 250 fan belts and the reorder point is 50. At any time I have 50 or less, I have to ask for reorder. Such a thing will be handled in addition, remaining page he will write the transaction history. So there is one page in the register. In that page top portion describes the material characteristics and the last portion describes individual terms. So let's say 14, 12, 0, 6, plant A asked for 25 items. At that point the balance became 130. 250 might have been the opening balance at the beginning of the year. I am just showing sample transactions here. Another date 45 items were asked by plant B. Another date 38 items were asked by plant A. Notice that this 47 represents reduction of the level below 50. 50 was the reorder point. This is the point at which that means 29, 12, the clerk must inform the material management of. Notice that there is another transaction request on 2nd January 2007, but that is okay because I still have material. Typically then the page in the stock register will look like this. So top page, I have hypothetically called it Power Electricals. The top page describes part code, part name, storage, location, etc. and the last part describes all the transactions. Please note that these transaction entries have occurred here based on the request notes that the plants have sent or alternately the invoices which are supplied by the supplier. Note that this entry is completely different. Some say CXVP said 31, 12. This may mean a purchase order given on 31, 12, because 29, 12 is when I reported that there was a shortage and this says 350, but here instead of quantity reducing it has increased from 17. Very clearly this is a supply of material that has happened. This is a simple and elegant scheme and many people follow this scheme. Now imagine you want to permit the stores clerk to use a computerised system to handle this. The stores clerk will have actual physical material around him but he will have a computer. So he will get request notes. Let's say he gets request notes still on paper, but you would like the records to be maintained, managed through a computer programme. If you have to write a programme, how would you go about doing it? It's not a very complex programme. All of you have done programming of this kind earlier or the other but can you think of designing a programme logically from the perspective of identifying not just the information but the way the information will be represented, the way computations should be made, et cetera, et cetera. That's a question. I mentioned the previous page if you look at, you notice there is a page number, 138. If somebody has 1000 items there will be 1000 pages. Suppose a request comes for fan belt small, how do you go to page number 138? Would you expect the stores clerk to remember? No. So there will be an index. Just like the key issue register with the watchman here has an index page at the beginning. So you will have an index page which will say part code this, page number this, page number this. Sometimes that page gets over and you are provided only one page. There are more transactions. Then the fellow will introduce a new page, copy the top information, start writing transactions there but he will write a new page here. Please note that without the use of this index it will be impossible for the stores clerk to handle the requisition quickly. Essentially then any backend storage that you plan must permit storage of the master information about part, must permit storage for individual transactions and must permit building of an index and its use in quickly locating the record in the file for that particular transaction. You can either do batch processing of all the transaction requests. What does it mean? For each requisition slip that the stores clerk receives issue the material and put the slip in a transaction file. Just keep storing it in a file. At the end of the day, update the appropriate item records in the ledger. This will cause delay in updating of information but handling of the transaction will be very quick. You are not wasting that fellow's time waiting for the material. On the other hand, you can do online processing. As each item is issued, search for the ledger page, update the quantity immediately. There are pros and cons of both approaches. Batch processing avoids delays in main activity that is issuing the material but delays information up. Consider submission of registration forms in the old style type. So all of you submit the registration forms. They are all accumulated by the academic office and over one week they enter the data but the delay will be in my getting the course list. On the other hand, an online processing where you submit your registration immediately and automatically the course list is being formed as you enter the registration. At any point I have the updated course list available to me. So obviously the OLTP is better. The operational alternatives for this activity is either a card X which is called a card index system. You may still find in small and medium sector units. They don't maintain computerized information system so they will have a card X, one card per part. And you will have cards which are stored on part code so that you can quickly access the card. Or an automated system which is programmed on a computer. Or you might have a very comprehensive information system implementing all aspects of accounting, payroll, inventory control, sales, marketing which is called an enterprise resource planning package, ERP package of which the inventory management will be just one part which will also be handled when you implement an ERP system. The desired OLTP or online transaction processing functionality for the store's clerk can be documented as follows. A, maintain a master file for part information. Now when you say master file you have to define a master record in that file. That record will contain so many fields part code, name, stock, etc. You collect data for a proposed transaction through a screen so you will collect a transaction record. There will be master record for all parts. There will be a transaction record which is a part code type of transaction. What do you mean by type of transaction? Issue or receipt. The quantity involved. There may be other information. This is just the bare minimum information that you require. And for each transaction the activity that you will do is read the master record for that part. Depending on whether it is issue or supply you will add this quantity or subtract this quantity from stock and rewrite the master record. Simple activity for a programming is not very difficult. But as I said, professionals don't start writing programs. They design. So far what we saw was the analysis part of the information. Now we design the program. So designing means you define very clearly what is the input to the program. So part code transaction type quantity of transaction. What is the master record? Part code, part name, reorder point, reorder quantity. The transaction log information will be designed. For every transaction you will create a log record in some other file saying this is what happened. This is important for non-repudiation later or this is important for finding out all the activities that have happened. And then exception report line. Stock falling below the reorder point at any time itself. You will have part code, name, quantity, whatever. You will then design sample record structure. So you will say a file on the computer will have a name inventory master file or enumast file. You will define a record name for that file which is a variable, which is a string variable let's say. You may call inventory master record. You will define the fields if that record. So first field may be part code which will be six characters long. Next field may be part name which will be 20 characters long. Next field may be reorder point which may be four digits long. Next may be quantity which is numeric five. Num four, n five, et cetera are different ways of stating the same thing. Incidentally if you ever have a brush with cobalt programming you will find that this is how you will design the record layout, the various fields in the record, describing whatever context you have to decide. And the sample records in master file may look like this. Notice the way the record looks on a computerized filing system. FB 1376 SMALR. There is no distinction. Why? You already defined first six characters are part code. Next 20 characters are part name. Next four digits are reorder point 0050. Although this number appears to be a single number it is not like that. These are different fields. There is no field separator required in computerized systems where the metadata is very clearly defined as how many digits mean what, how many digits means what, et cetera. Similarly a sample record in transaction file may look like this. So FB 1375. This is what you call part code. This may be transaction type R. What could be the transaction type R received? 0350 quantity. So such could be the design that you will do. And then you will write a program. I am not going through a program although I will try and put on the web model for this course a cobalt program for you to just read and understand that the logic of that program is not very difficult to fathom. But our purpose is not to learn cobalt programming our purpose is to learn information system. You agree that this kind of analysis and design is important before you undertake even writing a simple program. My humble suggestion is that in any endeavor where you have to write programs it might be useful to go through these steps formally. They will help you validate your own assumptions and so that you will make less mistakes in the program later when you write that program. We will very quickly look at the course organization. We have about 15 weeks of formal interaction. The slot for this course is six. As I explained in my notice the slot is notional. It is for avoiding examination clashes. So please ensure that you are not registered for any other course under slot six. That is important because if the exams are for this course and other course are kept at the same time then there could be a clash. That will not be possible. The formal sessions will comprise of the following topics. We will have an information systems view where we will talk about type and organization of system such as this session itself. We will then look at technology of databases, networking, web. We will also look at computer storage and I.O. technologies to understand how exactly these information pieces are handled inside. And then there will be sessions on methodology where I said software engineering, project management. So we will discuss these issues. We will also discuss implementation and operations issues of large systems. We will have some tutorials in between. I will announce the complete schedule appropriately where we will try and solve problems. All of you will be required to do course projects because this is not a hypothetical course. So you will have to practice what you are discussing and studying. So you will have to actually prepare an outline of an information system. You have to submit a detailed analysis. You have to do a design. All that you don't have to do is write programs. But since you are going to study databases I would expect you to write a square schema definition, a square queries and such things. Okay, so that's part of the course. The time required is about 40 hours of lecture tutorial sessions as is normal in any semester. Discussion sessions, self and group work would require at least about 30 hours for homework and assignments and about 45 hours of course projects. So this is the contribution that you will have to make outside the classroom. We have 5 hours of examination, 2 hours of mid-sem and 3 hours of end-sem which is mandatory. And the total work time is approximately 120 hours. I think that's reasonable. But that is the minimal that will be required. Less than that will not be sufficient. The evaluation scheme tentatively and I am open to suggestions and modifications is that assignments will constitute 20% weightage. Course projects will constitute 30% weight. Because project is something which you handle as a group and that is where maximum learning according to me happens in my experience. The project will have maximum weightage. There would be a minor project and main project will possibly combine these two defining different phases. So phase 1 could be a minor project, phase 2 could be a major project. And then of course written exams as per the senate mandate. To ensure that the practical work that you do has a larger component of evaluation the final exam will contain elements of the projects as well. So we handle it typically in two different ways. One will be there will be a question on the project that you yourself are doing. The other will be a question on some other project which is happening for which a presentation has been made here. So we will go through that. All of our exams incidentally are open notes examination. No books are permitted. But handwritten notes or printouts which are available as tutorial sheets or lecture printouts etc are possible. Let me also tell you those of you are not used to open notes exam. Open notes exams are tougher than closed notes exams because nothing of I mean describe something something etc. Such questions will not happen. There will be problems which you will have to solve. So often open notes exam generally means that you would have to read those notes very many times at home before you come here. Otherwise during the exam you are mostly reading the notes and time flies by. But still you have the access to those notes. Your own notes are permitted. No exchange of materials permitted. No carbon copies of notes are permitted. You cannot ask your friends to write using a carbon or something. But generally the idea is that you do not have to mug up any details of whatever the course discusses you should be able to solve problems. The projects will be done in groups and teams. I would expect three to four members to form a group. The group formation is entirely up to you and I would expect you to start forming these groups now so that when you come here next time you are ready with the identification of your group members. Different groups will form a team. Typically three groups will form a project team. There could be four groups also. I will decide based on the nature of the project. The project will be assigned by us once you form groups and the teams will be formed. Typically by taking your views we are basically trying to give you an exposure that if you want to understand how companies like Tarakansan Services or Infosys or such people do large projects for clients who are across the group somewhere who define the requirements and some people here do the analysis, design, coding, testing and deliver the working system. You should get a glimpse of that process. It is best if 12 to 15 people form a group and try to handle a larger activity. We will perhaps try and define a still larger project which itself is defined to be done by two or three teams each team handling a different aspect so that you understand what collaborative work is. Building information system in modern days is effectively collaborative work. So audit students will have to form a separate group. They will not have to appear for exams but they will have to do the project. The project for them will be to audit the project work done by others. So that is the way you learn without doing much work. The project activities will comprise formulation of the problem statement or system analysis producing a document which is called system requirement specification document. We will describe all of these in details later defining acceptance test criteria. How will you say that the information system is fully developed and ready and then doing a system design so you will have to produce a design document given, give a user interface usage manual. The development which is coding and testing will be limited to only writing SQL scripts and SQL queries which we shall be studying in details. Those of you who are interested in writing Java programs, HTML, etc. of course go ahead and code the whole system either now or later but that is not part of the evaluation as far as this course is concerned. These are the two references that we will use software engineering, a practitioner's approach. This is a book by Roger Pressman. This is considered the Bible of information technology professors today. This tells you very practical aspects of software engineering and database systems concepts written by Carl Silvershart and Sudarshan. Sudarshan is our own professor Sudarshan of Department of Corporate Science and I do not know whether this is the latest edition there might be a sixth edition but just cross check whatever it is. So that is the end of first session


So Bernadini, and he's talking about Terra Bruziata. Thank you. It doesn't matter. Okay. So, did you hear the news? Some researchers out and don't remember which university discovered that software has bags. They will get the novel for the obvious things. I guess you are not surprised, but I think that you should be. You see, four years ago Robert Dewar wrote this article that you can find on the network about why we shouldn't put with software glitches. In this article he points out that we accept in software a quality that is usually much lower than the quality we accept with our staff, say cars, TV or microwave ovens. Why is that? Well, he says, and I agree with him, that the problem is mostly cultural, and it's nicely summarized in this slide.  And since they are annoying, but the fact of life, people accept them. You will not accept a car that suddenly stops in the middle of the road, but you accept a software that gives you a blue screen over there. Yes, it's annoying, but you know, there is a turnaround, and what can you do? This is usually my reaction. Okay, usually I'm not that aggressive, but more or less the idea is that blue guy here made two mistakes. First, the word annoying. Buds are not annoying. They are dangerous. When I started making this presentation, I researched a while in the net for bugs that had some serious consequences. And the situation is pretty scary. This is just an exception of maybe the worst one. I guess, in my opinion, the scarst, sorry, the scarst one is the first one. Thermak, Terak 25, a machine for radiotherapy. If the user acted too fast on the interface, the graphical interface, a risk condition kased a excessive dose of radiation to the parts. And look at the Wikipedia entry. The entire description is pretty scary. Second one, I guess it's the third in that list, an intended acceleration that was a bit controversial. The car maker said that the user was making mistakes, pressing the accelerator on the side of the brake. Then it was the method that stopped the accelerator, but in the end it seems that it was a memory corruption that caused the throttle of the accelerator, stuck, full open. OK, I understand, I understand. As an Italian commercial says, ti piace v incere facile. That is, you like an easy win. You did some kind of cherry picking, you did.   OK, but what about, say, a music player? What does that mean? What kind of harm can you get from a bug in a music player? OK, please enter the last bug in 2015. Two researchers demonstrated that it was possible to take full control of a car by going through the entertainment system. The entertainment system was bugged, they hacked that, and it was connected to the bus of the car. They were able to control everything, wheel, accelerator, brakes. And the last one, it was in 2016, it was a wave of Daniel's service attack done by, sorry, done via some IP cameras. The worst one, it was an attack that sent a tsunami of data of one terabit per second to don't remember the target. And so the message, especially in the two last cases, is this. Even if your device is harmless, a player, a camera, a bug there can be dangerous, too, because it can trigger some small series of stuff and it can be used as a way to attack something. That is especially important now that the Internet of Things is getting fashionable. And this explains the strange video at the beginning. How can a tool brush bring down the poor grid? Well, it's easy. You have a tool brush connected to the Internet. They exist. There is a big brand that is selling them. Don't ask why. I cannot understand why you could want your tool brush connected to the Internet, but they exist. If they had a bug, they could be enrolled for a Daniel's service to say the power grid, the stock market or whatever. So, sorry, too fast. So, at this point one could say, OK, OK, OK, you sold your point. Bug are dangerous, are serious stuff, but they are unavoidable. So, they are not really like bad weather, but like more meteors, dangerous, but you know, you hope that it never happen. And maybe you can have some kind of passive defense through backups or build shelters in case of meteor strikes. Actually, having the word unavoidable, OK. And the fact that this idea is changing is reflected here. This is in piece of news about a bill that was proposed in US in order to secure the Internet of Things. So, they recognize that the bugs here can be dangerous. And look what they do. They ask that the software is patchable. They are not asking for software that works. They are asking for software that can be patched because the basic idea here is that bugs are matter of life. And even this is not true. The user, according to example, is a bionics. 737 has 7-8 millions line code. How many lines of code flew over our heads so far? And there is not a single incident that brought to a death of someone due to the software. So, yes, the user's lecture is, OK, it's possible to write good software, it's expensive, it's time-consuming. And since it's time-consuming, we cannot do that because we need to be fast, fast, fast to get to the market. To counter-objection. First, that's not an excuse. There is my life at stake. So, if it's expensive, too bad, sorry for you, but you are going to write good software. It seems that it's not really so expensive as many believes. Talking with someone who works with the O178, that's the certification standard for software running on planes, I was told that if you do the things correctly, and that's a big if, that is, if you think your process in order to complain with that standard and do not try to do the standard of your process, the increase on a plane is more or less maybe 45%, not 200, like sometimes you hear. OK, 50% is not negligible. But it's not even so huge. So, OK, good software can be written. It's important that it's written, but nobody does that. What are you going to do? What am I going to do? Welcome to Terra Bruciata. Terra Bruciata is the Italian expression for scorched earth, that strategy where you burn everything so your enemy has no resources. And the idea is to burn the ground around the bugs so they have no more place to hide. More precisely, my vision, as your PHB would say, is to bring process, tools, ideas from the high integrity software context into the open source software context. It will not be easy. The high integrity staff was born in industry environment. So, for example, the O178 was born in industry environment. And in industry you have a hierarchy with your boss. Your boss say, starting for tomorrow, we are going to do this way. You say, why? Because of the boss. And say so. If you don't do this way, you are fired. Maybe many management book would not suggest this strategy, but it will work. In open source, of course, you cannot do this way. In open source community runs mostly by volunteers in a distributed way, so it's a different environment. And try to adapt something born in industry environment to this one, maybe it's a bit challenging, but we can try it. Why? What I think to achieve? Well, three objectives. The first one maybe is the most obvious, but not the most important, to produce better software, which is something that is good itself. But the second objective is to make an example and show other people that this is possible. I hope to attract to this idea other open source communities, but also I think that it will be important, let me say this, to let know everyone that writing good software is important and possible. Even without being a software house that works for Airbus or Boeing. This should be known not only to taking people like us, not only to your C-suite, but to everyone. Because what we want is a kind of market pressure. People must get enraged when the game is the blue screen of death. And finally, an interesting side effort is that we, most probably, we need to develop processes, tools and way to use some sophisticated tools like formal checking in open source context. And this experience, these tools could be used by other developers, open source or not, to help producing better software. So this is not really, let's say that the main objective is the second one. The first and the third are nice side effects. So I told you about the why bugs are serious stuff. The what. I want people to write, sorry, the why bugs are serious stuff. The what. I want to distribute to promote an idea of current software. Remember that Robert, you are saying that the problem is cultural. We are trying to address the root of the problem. And now, let's talk a bit about the how. So what kind of software we are going to develop? Maybe it was to start with something quite peculiar that is libraries for little protocols. The little devil there was added today while I was at the other developer room. And I saw in a talk about using other in little better environment. And that could be another interesting thing. But you know, we start taking with the original plan. And if you get enough people, attract enough interest, you can start also this branch. This just was added four years, four hours ago. OK, so the idea of starting with network protocols is quite peculiar and neat. But there is a reason. Actually there are two or maybe three. The first reason is that networking today is very important. And there is another nomination to the novel for the obvious stuff. Actually, many people believe that programming is just a web development. So we can agree that networking is very important. And it's useful to have some safety implementation of that. That's quite interesting. Actually, there is more to that. The networking part of your application is the entrance gate of your application. And if your gate is weak, you can build a castle as strong as you want. But the whole system will be weak. And moreover, what's worse, if you have a library with bugs that is used like a network protocol as a building block, this library will be used in many applications. And if there is a bug, you will have lots of bugs around. Do you remember HeartBlood? That's the same idea. So since we need to start from somewhere, this could be an interesting context where we can do a very strong impact about safety. Moreover, there are another couple of reasons. There are a couple of reasons. Let's say we try to get tubers with a stone. And that could be useful also for protocol development. The ITF has two tires for protocols. One is a proposed standard and the other one is an interstandard. In order to be promoted to an interstandard, they need at least two different implementation of the same protocols. Why? The idea is quite obvious. If you have two different independent implementations, the word independent is important, that talk each other, then you are quite sure that the specification of protocol are not ambiguous and complete. What happens usually is this. While the protocol is being developed, someone writes a library for that protocol. Some software for that protocol. Because in ITF they believe you're running code. Correct. So at least one version of the protocol is available. Starting from that, in many cases, if you need another library in the different language, you don't rewrite the same library from scratch. But use the first one, use written in C, and do a binding. And you know, if you have a Ruby binding for a C library, that's not an independent version. It's the same code with the progress. Since in our case we are interested in developing correct software, we have a reason for rewriting the stuff. If we have a nice effect, we can get an independent implementation for promoting the code to the higher tier. And moreover, ITF is trying to have some connection with academia and with open source communities. We started this initiative that's called CodeStand. CodeStand is basically a way to connect. You propose some project to be implemented and keeping track of who is implemented and what. This is the homepage of CodeStand. I can see really not many belly whistles, really to the point. And I don't know if someone of you have ever been in an ITF meeting. If you want to have any idea what an ITF meeting is, take post them and make everyone 20 years older. You get the idea. It's a very special group. Still working by a mailing list. I guess they are the last ones. They are the last ones who still work and communicate via mailing list, but it works. And staying at an ITF meeting is something that one should go just to see the environment. And this, for example, is CodeRequest. So these are open teams for someone who wants to try to develop this stuff. And we could be a nice channel between open source and ITF. Let's say this is not the most important result, but it's a nice side effect. Still staying on the side of how. Let's go a little bit technical. And this is something that I feel like in the need of explaining maybe the final bit. So the idea is to develop this stuff using if possible Spark and Ada. By the way, Spark has nothing to do with Apache. It is a subset of Ada that is suitable for formal checking. Formal checking means that you have a piece of software that can check if there are no, say, no buffer overflow, there are no exceptions. You use everything when it has been initialized, but also you can have the program to formally prove that, say, your function actually does what it says to do. Pre-condition, post-condition, and the Spark can check that if the pre-condition is true, given the code, the function, the post-condition will be true. This can help a lot, actually, helps a lot in finding bugs. That's the idea that I have about Terra Bruciata. This is a way to burn a lot of ground. This is not to burn all the ground. There will be still something that you can do in Spark, something that you need to do with testing, but this can help work quite a lot. And the usual objection when I talk about Ada is that it's old. I'm not going to do another advocacy of Ada now. Usually, here, first, there is the other developer room. You can go there for more deep discussion. But basically, the idea is that, actually, I used a lot so far. I graduated more or less 50 years ago. And in all those years, I used, I don't know how many programming languages. And I used C, C++, and other stuff. My personal experience is that the bugging with Ada is much, much faster. Let's say that it won't help the effort, really. If you help the compiler, you can be really, really a strong head. It's not a magic bullet, of course. Usually, the objection is that the real quality comes from the programmer, not from the tool. And it's true. I agree. But even a chef needs to do something complex like letting a fish. Prefer to use the flexible knife because the job is done faster and maybe with better quality. So even if you are a professional programmer, you have a lot of experience, you will prefer to use a better tool that helps you in the job, basically. And believe me... OK, the other objection usually is about speed, but Ada is compiled, like every other language. So, more or less, there is no... And actually, it can be used on very small devices. A few years ago here in Bosnia was a talk that showed the Lego Mind Stone program in Ada in order to make an invest pendulum segue. And it was a multitasking code over the Mind Stone that is 16-bit CPU with, I don't remember, 64 kilobits of RAM, stuff like that. So it's not only something that runs on planes. And, well, this objection, I guess, it's not... So, what time is it? OK, a little bit early, but I guess. OK, what is the current status of this? This is quite a young idea. I got this idea maybe less than one year ago. Currently, I'm working myself with a couple of students of mine that should graduate in the next few months, so I will be left alone. And I started with trying to implement co-op. I don't know how many of you know co-op. Co-op is a lightweight HTTP. I'm not telling the spirit of HTTP, but it's based on UDP, not TCP. And it's all binary, while HTTP is text-based. This is all binary. This was developed for the Internet of Things, as usual. Why this? Honestly, no special reason. We need to start from somewhere. This is connected to Internet of Things, and it is important nowadays as an applicative level. So, we started with this. We are currently trying to get from the RFC to summarize it in a few formal statements of requirements, and from that, starting developing with more or less the idea that you can find in DO178, minus all the bureaucracy that DO178 has. And so, the idea here is to try to collect at least initially a condensation core of people that can be really interested in the idea of writing correct code. So, if you want to get in touch with me, here there are my email address, my LinkedIn page. There is also a LinkedIn group. And maybe... Oh, no, maybe. There is also a page on SourceForge, but I forgot to put the link here, but I guess you will be able to find it. And I hope here there is someone interested in this stuff, so it's something that's starting. So, it's open to new direction, so it's open to commenters, open maybe the idea of using or writing method protocols maybe can change. I don't know. If there is enough convinced arguments, maybe it can change. Maybe we can start also different branch, for example, in bed or other stuff. And that's it. I open to question if you have any. I guess I'm a little bit early, but I think you will not cry. Thank you very much, first. And here's the first question. Yeah, hi. Janik Moj, project leader for Spark at Decor. So, I have one question and two comments. So, my question is how did you make your slide? And my first comment is about what you said or what somebody told you about building avionic software that costs only 50% more than regular software. Just to dismiss any misconception that's not true at all. So, NASA documents some years ago counted something like seven times more investment in verification phase with respect to development for this kind of software. And even last week, I was at Avionics conference and Airbus presented a big project to reduce the cost in DOA in 78. And they were saying that for their typical product verification was 70% compared to development 30%. And I could go on about all the development assurance that you need. Much more than just 50%. Just so that you know, high critical software really requires much, much more. So, you cannot just copy paste such processes. But it's nonetheless, my last comment is obviously we are very supportive of a project we use the kind of technology that I use in Avionics and other domains. Just wanted to say that even though seems like a good idea, these kind of initiatives in individual project have been going on for many years already. And, for example, I encourage you to look at Muen. Muen is a separation kernel written in Spark. It was led by this person next to me when he was at CQNet. And this separation kernel is something quite big where you ensure security of applications by having a kernel that ensures that it does not interact in a non-esplores way. And this kernel is a small kernel in Spark that has improved absence of front-timers. So, there's no possible tax of many different kinds. So, just to say, it's a great project, but be aware that there are many others open source project with these technologies. And there's one more question. Well, okay, thank you. The figure about that, and I found that 50 percent I found in a book, but I don't remember the title, it was about. But I'm not, so, just to be clear, I'm not an expert, I'm studying this stuff right now for this reason, but... And about the other initiatives, actually I was in the other developer room when you talked about them, and I was happy to hear that I'm not alone. Let's say that maybe this also has a different flavor. The other initiative was, let's produce, say, an expiration kernel. I don't remember the other stuff. Here the idea is let's do this. Also for the public relations stuff. So, if they produce good software, it's also to say to the world, look, good software can be done. To try to... Definitely a good idea. Just to say, there are other things that you could look at or others could look at. For example, in terms of examples, Tokenir example was produced by Alton in Spark for DNS in 2005. We open sourced it in 2008. Everything is on the web. By the way... There are others to look at for inspiration in that case, as examples. By the way, I will look also... Today I discovered about those projects you talked about, and I plan to look into them, for example, to see for idea processes and how they did that to do import in this context. So, actually, I repeat, I'm happy that they are not alone in this. So, I feel a bit skeptical about the idea that if you demonstrate that you can build correct software, then overproject will start adopting the same methodologies. One reason is that, as was pointed out, there already exists software that was developed to be verified from the start. And yet, the methodologies are not common in the open source community, for example. And sometimes, I think maybe it's because the tools that have been used in the Spark at that community, all the people that do stuff with proof assistant and so on, are very different from the tools that are used in existing projects. And maybe what we also should do is start trying to adopt tools for formal verification in important open source project of today. I was wondering if you had the opinion of that, because I worry, so you would build a protocol implementation in Sparkata, but then people could say, yeah, it works because it's Sparkata, but we are I don't know, a Java shop, we see right now, so we cannot use this methodology. Okay, so first about what you said at the beginning, you see those projects, I discussed about those projects today, and they have an interest in correct software, i, development and other and stuff like that. So maybe what's missing is, I know that maybe in this context I'm going to say bad word, but kind of marketing stuff. So letting people to know that to actually try to spread this idea, not just because for example, those projects I discussed today, and I have an interest in this. So Just to answer it, because I think there's an answer, these domain, these tools for formal verification, higher critical software, it's very open source rich. You have plenty of tools that are open source and particular industrial tools. So for example, if you do C, C code, there's Framacy. Framacy is a well known tool. It's not adopted very widely because all these incur a cost. So if you, I mean for our software, for building our own software in Ada, we don't use our sales part because it would be too costly, we'd have too many constraints to develop a tool that is not as critical and so just to mention, for C would have Framacy that implements the same thing with the underlying same building blocks, in fact, from also the open source community, so open source provers. For Java, you have OpenJML, which is also open source. So you have framework tools like that that are available for a few languages. I believe that for C code for the drivers, people have used CLEE for example, model checking of C code. So I don't know the state exactly of that, but for Microsoft there was SLAM and I guess there are many, many tools and it depends on the motivation of communities. Higher critical software may require more effort, so again it depends on the motivation of the community. I like the initiative to make a more secure infrastructure. On the other hand, I just did a project on an x-ray machine and I think 60 to 70% of our product code was test code. So I think the current test infrastructures if you expand them and they get attention we would already get there and another lots of problems is indeed the legacy of C in C++ that hurt us. So other could be a solution or rust or I don't know what other initiatives there are. So I wish all the luck with this initiative and I hope more do follow. Hello. I was wondering and I don't know if you can give us some figures if, for example, I'm thinking about the Linux kernel. There is a lot of critical open source software that is used heavily in production nowadays and I find it difficult to believe that some kind of formal software was not already applied on the large scale on this kind of software. Do you have some idea about what was done already in this field? At the industrial level I don't know, but doing formal verification on languages like C maybe I'm not an expert in this field but I think that it could be much more difficult than using other tool because if you want to do formal verification you cannot use pointers and if you write a C without pointers you do not do much. Having just passing parameters that must be written by a function you cannot do that. Instead in other those use pointers are hidden by the language so for example you say that this parameter is not parameter of course the compiler will pass the pointer but it remains hidden so you can avoid using pointers but disclaimer I'm not an expert in this field I would like to maybe give an expert view on this one pointers can be used in formal verification the more pointers you have the less it's easy to do and for example VCC is a tool that was produced by Microsoft Research now it's used at Amazon to formally verify C code that is used to formally verify C codes in industrial context Open Gmail obviously is used to verify Java so you can and just to answer because there was a question languages matter a lot for this kind of things last week Xavier Le Rois the creator of Open Gmail give a presentation on that he started, although he created this compiler from C to assembly he started by saying that C is ugly and you cannot really work around it this morning person doing the presentation on software quality in Mozilla just to urge people to move away from C++ to rest Xavier Le Rois would go to Open Gmail just know that there are other alternatives than C and C++ and that the language matters if you want to go to that level I was going to ask if it's kind of a project founded by a university it's frankly I it's sad to see such things occupying space in universities for future generations so far there is no funding more or less it's me working on on following students who are graduating and the amount of resources are not it's not huge and by the way I believe that it's something that can be useful okay it's important for the future I mean having this promoting this idea and also teaching students that software must be good because it's important and teaching them skills about how to write good software I believe it's really important so thank you very much Ricardo welcome