The Next-Level BIM Electrical: Embedded Analysis Using Revit API

AHMED ATTIA: Good morning, everyone.

AUDIENCE: Good morning.

AHMED ATTIA: Thank you for attending my class, The Next Level BIM Electrical, Embedded Analysis using Revit API. My name is Ahmed Attia. I work as an electrical engineer and a BIM specialist for the Dar Al-Handasah, Egypt.

A little bit about me. I'm a licensed professional engineer in Colorado. I spent the first eight years of my career working as an electrical design engineer for multiple consultancies in the Middle East. I moved to being a BIM specialist for Dar Al-Handasah for the last three years, working on developing electrical BIM workflows for-- electrical BIM workflows with a focus on electrical analysis and BIM for sustainability.

So Dar Al-Handasah is part of Dar Group, which consists of 14 companies, including Dar, Perkins and Will, TY Lin, Ross & Baruzzini, Currie & Brown, and other companies. We have been one of the top 10 consultancies around the world for the last 10 years. We are the seventh in 2018 in ENR 225 Design Firms rating.

So today, I will be talking about our experience at Dar trying to include electrical analysis inside Revit using the API and why, as electrical engineers, we are-- electrical and MEP engineers, we are still struggling to include electrical analysis into our BIM workflows. There will be no specific API coding instructions, but rather ways to think of the API for electrical analysis.

And the methodology we followed at Dar to include electrical analysis into our BIM workflow, towards the end of this session, I will be displaying a three-minute video explaining the full solution we reached at Dar. There will be a dedicated 3-- a dedicated 10 minutes for your questions at the end. So please, if you have any questions, write them down and wait until the last 10 minutes.

At the end of this class, hopefully you will be able to follow a systematic methodology to include the electrical analysis inside Revit using the API, understand how to use an external database to store design electrical analysis related data, understand how to introduce custom calculation settings inside Revit using the API, and get introduced to some Revit API useful capabilities.

So before proceeding any further, I'd like to get to know my audience. So by show of hands, how many of you are electrical engineers? Yeah. OK.

BIM specialists, BIM managers? Great.

Any software developers? OK.

Any upper management directors? Great. OK.

Hopefully, at the end of this session, I will have delivered a message for each and every one of you.

So where are we? Where have we been? And where are we going to?

For years now, we have been using Revit at Dar. We spent so many time trying to produce the highest quality BIM models ever. We spent a lot of time trying to create our own families, our own libraries, our own shared parameters. We filled those shared parameters with a lot of design-related data.

But for quite some time we struggled to include advanced analysis, like short circuit, voltage drop, cable sizing, into our BIM workflow seamlessly. So for quite some time, we tried to use the integration with other external software. We tried using some third-party commercial tools that claim to perform electrical analysis inside Revit. But that didn't work out. And in minutes, I will explain why.

Then lately, in our efforts to automate our BIM workflows more and more, we thought that moving electrical analysis inside Revit might be the smart thing to do, which is the topic of today's session. But that shouldn't end there. We are thinking to develop this in the future to a fully optimized electrical BIM workflow, where we can produce the highest quality electrical analysis with the best possible results.

So why, as electrical engineers, we are still struggling to include electrical analysis into our BIM workflow? You can think of many, many reasons why is that an obstacle until now. But I think the four main reasons are the following.

First, we have multiple codes and regulations. We have the North American code. You have the European codes. You have the British standard. You have a lot of local regulations. And to find a single solution that fits all of this and at the same time works with your BIM workflow, works with your BIM standard, with your organization's BIM model is really not a simple task to do.

Second, we have a lot of electrical analysis tasks. And these tasks are not like single formula, single output kind of tasks, but it's rather a loop of interconnected analysis, where each analysis might affect the input or output of the next analysis. For those of you who are electrical engineers, know exactly what I mean. If you are doing a cable sizing, you might change this cable size later based on voltage drop analysis. So it's rather not a linear process that we can include easily into our workflow.

Third, we have multiple external softwares. And each external software does a certain type of analysis or multiple types of analysis. And to solve the integration problem, to have a single integration to all of these multiple external softwares with software developers moving slowly into BIM was not possible until now, at least in our own experience.

And fourth, we tend to have a lot of experience-based assumptions and design criteria that leads us some time to program our own spreadsheets and calculation sheet so we can reach the final output we want.

So for all these complications, we thought that moving analysis inside Revit might be the smart thing to do for now. But for that, we needed to create a new process. We need to invent a new process.

And in this new process, we needed to know three things. We needed to know what was wrong with the integration problem, what went wrong with-- why didn't we-- why weren't we able to do a full integration with other [? stone ?] software, and what was missing, so we can avoid it in this new process? We needed to think, what is missing inside of Revit so we are able to perform all of these advanced analyses that we want, and include it? And finally, we needed to know how to customize the whole process to our own BIM standard, to our own design deliverables.

So first, the integration problem. For quite some time now, we have been testing and trying a lot of commercial tools, a lot of commercial software that claims to have an out-of-the-box capability to integrate with Revit. But that didn't work out for the following-- for the following reasons.

First, most or all of these tools did introduce its own standard of BIM. It did introduce a lot, a lot of shared parameters that we had to include into our already established BIM standard and already established templates and schedules. And that was not very practical.

Second, all of the tools we have tried, we didn't-- we couldn't customize its internal database. We couldn't introduce new manufacturer data inside the software. We couldn't introduce our own custom data that might work in a certain region or a certain country.

And finally, most of these-- most of these tools only conformed to one code or one regulation. And when you are working in a multinational consultancy like Dar, we operate in 40 countries in the world, we can't have that. We can't have a tool that conforms to a single code or single regulation. We need something that conforms to most or all of our codes and our regulations.

So moving electrical analysis logic and formulas inside Revit seemed like the smart thing to do. But is it enough to include or program some analysis logic and formulas inside Revit?

Actually, no. We needed a lot more. Besides analysis logic and formula, we needed some way to control custom calculations settings. Whenever we thought of trying to include all of these types of analysis, we need our engineers to be able to tweak the final output of analysis, to control the final outcome of analysis, so we needed to introduce a lot of custom calculation settings that need-- that our engineers can change during the project.

And second, we needed something we called for the sake of this presentation calculation references. For those of you who are electrical engineers know these calculation references as your current carrying capacity tables, your cable data, your standard breaker ratings, your standard NEC tables for demand factors. And for those of you who are not electrical engineers, calculation references are these large sets of tables and charts and standard sets of values that we tend to reference in the middle of our analysis to extract certain values and input to our analysis to reach the final output.

But we didn't find any out-of-the-box capability inside Revit to include all of these data unless we used hundreds and hundreds of parameters, which is not very practical. So we thought to integrate Revit with an external database, simple form of external database that we can extract these values from, feed into our analysis, and finalize the final output.

And finally, we needed new custom user interfaces. We need to introduce new custom user interfaces inside Revit so our engineers are able to work on these new features, to input certain values, to track the electrical analysis process.

But is it enough to introduce this new process? Actually, no.

We needed to know how this will affect our data exchange process. We needed to know how it will affect our project roles. And we need to know how our engineers' design tasks will change.

So we decided to test this into one of our complicated design tasks, which is MCC schedules, or Motor Control Center schedules. For those of you who are not electrical engineers, MCC panels, or Motor Control Center panels, are a special form of electrical panels with special feeding requirements and protection requirements, and include an extensive set of electrical analysis due to its nature.

So how did our original process, our classical process look like in producing these MCC schedules before introducing automation? First, electrical engineers requested electrical supply requirements of mechanical loads from mechanical engineers. Mechanical engineers provided these loads tabulated in spreadsheets or any form through email. And then electrical engineers gathered to agree on design criteria, motor starters, protection requirements, the design conditions.

Then electrical engineer performs a large set of advanced analysis. And the final output is tabulated to spreadsheets or any form of tabulation totally outside of Revit. And this was our workflow whilst we were using Revit.

Now let's see what happens when we follow the design changes in this process. What happens when mechanical engineers do these design changes, decide to change the number of chillers or the number of air handling units they are using in a certain project. And for those of you who are electrical or mechanical engineers know how often this happens.

Now you can simply notice that we almost repeat the same process over and over and over again. Now, what do you think is wrong with this process?

We have a lot of duplicate effort. Mechanical engineers, every time they change, they tend to send the information to electrical engineers. And at the same time, they have their own families and templates and Revit BIM models that they need their design-related data to be included inside it. So they input the same data inside their models too.

So there is a lot of duplicate effort. And at the same time, there is a lot of abortive work. Electrical engineers tend to perform the same analysis over and over and over again whenever there is a slight or a major change.

Now let's look how that was modified by automation. Now, mechanical engineers are responsible to input electrical supply requirements to mechanical models. Electrical engineers are responsible to customize calculation settings inside their model. And this is, you can see, a screenshot of one of the new interfaces we introduced inside Revit to customize calculation settings.

Then, through the API, the mechanical electrical supply requirements are transferred automatically to the electrical model. And the API consults an external database for all the calculation references I was talking about, and feed it into analysis to finalize the process. And then the final output is tabulated to a pre-set list of shared parameters and MCC schedule templates.

Now let's follow the same design change arrows that we followed in the first process. What did you notice? The [INAUDIBLE] work has gone. Mechanical engineers need to input their electrical supply requirements only once. Sorry-- the duplicate effort is gone. Mechanical engineers input their electrical supply requirements only once.

And the abortive work for electrical engineers is almost gone. Electrical engineers now each time they need to perform the electrical analysis, all they need to do is verify or change their calculation settings.

Now let's look how this affected our classical design tasks. Originally, we did those design tasks. We did some data extraction, as in calculating the number of elements on your circuits, or even receiving electrical supply requirements from mechanical engineers.

We spent some time on calculations. We spent some time on data tabulation and layout, as in MCC schedules or panel schedules. We spent some time on design criteria and concept. We spent some time on drafting a layout. We spent significant time into redesign and design changes, enhancements, mistakes, and also the sample I was talking about, the design changes for mechanical electrical supply requirements.

Now let's check what happened when we tried the automation. Now, the data extraction is gone, since it's totally automated. The calculation time is enhanced. And now the calculation is more accurate, since the calculation input is more consistent and up to date. And the data tabulation task is totally gone. But the most important part is design change time is significantly reduced, because we automated the part that resulted in this design change significant time.

After some testing, we thought that fully automating our electrical analysis would probably result in about 40% saving of our resources and man hours. I think you can imagine the thousands of hours we can save if we fully automated our process through such solution.

Now, since this was a fairly new application into our organization, we needed to invent our own action plan, our steps for implementation. And what we noticed during this, that it was not about specific API coding capabilities.

It was about the methodology to implement it. It was about the methodology to crack all of this complicated analysis into a certain simple form that can be inserted into this new solution. And for that, we came up with this five step plan.

First, we needed to break down our analysis into small, manageable chunks. We needed to break down our analysis and label each part as into where it will belong in the new solution. And I'll explain that in detail in minutes.

Second, we needed to work on our standard BIM objects. We needed to work on our templates, our families, our libraries, and see what's missing in these families so we are able to do the full automation. And third, we needed to create a flow chart that we can lay out on the main features of this new solution.

Fourth, we needed to create the custom database that I was talking about that will include all of our calculation references and solve the problem of conforming to multiple codes or regulations or even manufacturer-- or having to insert manufacturer data instead of the standard ones available in code. And finally, we needed to design the new custom user interfaces that we needed to introduce to Revit.

Now first, breaking down our analysis. For breaking down our analysis, we followed these steps. First, we had to determine which types of analysis we want to do.

Do we want to do short circuit? Do we want to do cable sizing? Do we want to do volt drop? What are the types of analysis that we want to do?

Second, we needed to group a set of values that we called global settings, custom calculation settings. And these are usually the values that are preset at the start of any electrical analysis project and affect the final output at the end. You can think of ambient temperatures. You can think of voltage levels. You can think of frequencies, any value that are preset at the start of the project and will affect the final analysis.

Then we needed to group our calculation references that we will need for all these types of analysis. For short circuit, we might need the percentage impedance for transformers. For cable sizing, we need cable data, and like this.

And then we needed to define our analysis logic, as in analysis inputs, list of formulas, analysis outputs. And where will we get these inputs? Is these inputs are transferred automatically, as in the case of MCC schedules? Is it-- will this be an input from the model or through our engineers? And the list of formulas, all the list of formulas that we need to process these inputs into the final outputs that will appear on our design deliverables.

Second, we needed to work on our families and libraries and see what is missing for these families and libraries, either to extract a certain type of data or to show the final output of analysis. And for that, we categorized our new parameters into two categories.

The first category is analysis input parameters. These are the inputs that will participate in the final output of analysis, that are the inputs for the analysis logic and formulas. And they can be either filled through our engineers or automatically filled by automatically transferring from mechanical model, as in our sample.

And the second category is analysis output parameters. And these are not any intermittent values that we might process during our analysis. But these are the final outputs that should appear into our final design deliverables.

Third, we needed to create a flow chart. This flow chart needed to lay out the main feature of our new solution. This flow chart needed to point, where will we connect to the database and extract certain values, and where will we feed these into formulas to finalize calculation, and when we will write the final output to a model? And the most important part is it showed us where we need to pop up these new custom user interfaces for our engineers either to extract certain data or input certain data.

After that, we needed to build this calculation references database. And this was the most-- this was the whole idea that this is the problem that we faced with integration. We couldn't customize any calculation references. We couldn't customize the cable data.

So this was the most important part, building our database. And for that, we followed this four step process.

First, we needed to summarize our data categories. Do we need cable data? Do we need transformer data? Do we need equipment cut sheets? What do we need to include into our analysis so we are fully satisfied with the final output?

Second, we needed to customize these categories of data, these tables of data, these charts of data to our own needs. You might need a cable data table, but you don't need the weight. You don't need certain information that are available in the original table or the original cut sheet or the original source that you got your data from. So we needed to just include inside our database only the data that is needed to finalize the analysis.

Third, we needed to define the technical sources. We need to define, where will we get these data? Where will-- will we get this from a code, regulation?

Is this a table in the NEC? Is this a table in the IEC? Is this a data sheet from a certain manufacturer that we need to reference in our analysis?

And fourth, we needed to tabulate all of these data into a database management system. And for that, we used the simplest form of a database management system, which is an Access database. And if you have your handouts now, you can check this in page 9. You will see a screenshot of the simplest form of an Access database we have used.

And lately, we have been thinking to move into a more sophisticated database management system, like code-- sorry, like cloud or a SQL Server. But the simplest form will just work as fine as any other database management system.

Now, whenever I say new custom user interface design, some of you might think that we need to revert to a professional software developer to do this task for us now. But what I mean is not the aesthetics of the new interface, is not the programming part of the new user interface.

What I mean is the technical point of view of this new user interface, what data you need available for your engineers so they can input to customize or tweak the final analysis. What are the default values for this data?

What are the minimum and maximum values for this data? You might need to limit your analysis to a certain limit. You need the maximum ambient temperature to be at 60 degrees, at 40 degrees, the minimum at minus 10, whatever limits your analysis into a certain range that you don't want to get out from.

Now, for those of you who will take the coding part themselves, even you are an electrical engineer or a BIM specialist or not a professional software developer, or even if you are a professional software developer, this step should help you massively into finalizing your output in the correct way. You need to pinpoint the main features of your final solution and think, how can I do this using the Revit API, or is it doable using the Revit API?

This was the main features that I needed inside my new solution. First, I needed input from other trades, so I had to know how extract certain values, extract certain parameters from linked models. Second, I needed to do some accumulative or dependent analysis, like the [INAUDIBLE] analysis, for example. So for that, I needed to know how to extract the electrical system hierarchy.

And by the way, in this new process, we thought that we will use the full electrical system of Revit. We will connect all circuits starting from transformer to MDB to SMDB. I know most or some of you are using only the distribution panels level, where you connect circuits to distribution panels and then do the rest of your work outside of Revit. So did we. But we decided that we need the full electrical hierarchy inside Revit.

Third, I needed to track input errors. I was importing data blindly from another model that I don't know how many duplicate data are there, what values are right or wrong. So I needed to come up with a certain code that will track model changes.

And fourth, I needed to do feeder and protection rating analysis. And for that, I needed a way or a certain block of code that will interact with an external database and bring me the values and I need to input to the final analysis.

And fifth, I needed to record the output on model. I needed my engineers or the design deliverables to include all of these final outputs, so I needed a block of code to learn, and test a block of code that reads and writes certain values or certain parameters from and to the model.

And finally, I faced the problem that its solution was something called Revit's Extensible Storage. And I will explain this problem now. So when we introduced new custom calculation settings inside Revit, our main problem was when these values change, where will we store this changed value so when you close your model and reopen it again it's the same value?

You need the custom calculation settings, of course, to be consistent along your project. You don't need the ambient temperature to change from 40 to 60 when you close your model and open it again. So we needed a way to store these values inside each model.

The simplest form was to think of storing these values inside shared parameters. But storing it into a shared parameter will make it prone to unintended change, to mistakes. And this could ruin all of the analysis process in an unintended way.

And after some research, we learned that Revit API offers some something called the Revit API Extensible Storage. And this feature allows you to store structured data inside Revit hidden from user in two ways.

One of these ways is to attach it to a virtual object called an entity. And this way was perfect for storing the custom calculation settings inside each model specific to each model. And the other way is to attach this list of structured data to each instance of your family. And this was perfect for storing the final output of our analysis hidden somewhere before we write it to our shared parameters and make it visible to our engineers so we always have a record of the latest and final output of our analysis hidden and protected somewhere.

So I'm done now. I think I will leave you to watch the three-minute video of the full solution. And after that, we can move to your questions.

[VIDEO PLAYBACK]

- Good morning. This video will describe Mode Control Centers automation workflow using Revit combined with Revit API solution.

Engineer starts by placing electrical fixtures in the model in proper locations corresponding to mechanical equipment needing electrical feeding. Fixture family is ready with all parameters needed to store electrical requirements and analysis results later.

Next, engineer customizes electrical settings inside model, such as selection of standard breaker ratings and general settings to be used later in analysis.

Engineer is prompted to select mechanical link to automatically transfer all equipment electrical requirements to electrical fixtures already placed in model. All mechanical load-related data are transferred to electrical fixtures' corresponding parameters.

Both models are checked through the Application Programming Interface for duplicate elements or discrepancies between electrical and mechanical models. Equipment with proper feedings are shown in green for being ready for the next step, and other equipment are shown in red.

Engineers start circuiting fixtures to corresponding MCC panels in order for the API to use circuit data to perform required analysis. Once all circuiting is done, engineer executes panel schedule filling in a preset template customized to company standard presentation. All circuits are scanned for detailed load description and filled to schedule.

At this point, engineer executes feeder sizing based on circuit data and previously customized settings. Feeder ratings are selected through scanning a preset external database for proper ratings.

Calculation settings, such as cable type, can be modified and accessed any time through the project, and output is recalculated and modified accordingly.

All final calculation results are filled to electrical fixture circuit parameters.

[END PLAYBACK]

AHMED ATTIA: So before proceeding to your questions, I have only one question left for you. If you feel like you have learned something new today, please raise your hand. Thank you so much. Your questions. Yeah.

AUDIENCE: How much data can you successfully put in extensible storage in a file? Does it get loaded to [INAUDIBLE]?

AHMED ATTIA: Actually, I didn't need to put this much data. If you combine the calculation settings, which is maybe like 10, 20, 15 parameters maximum, and combine that with the final output of analysis and compare that to already the shared parameters you have inside your model, you won't find this too much. But the Revit Extensible Storage, from my own experience, is very stable, very-- it didn't show any problems with me. Yeah.

AUDIENCE: In the mechanical model, was there a special API call to that so they can speak or talk with the API in the electrical model? Or is it just [INAUDIBLE] data that is out of the box in the mechanical model?

AHMED ATTIA: No. The Revit API offers the capability to interact with the models and extract whatever you want. The only thing we did with the mechanical engineers is that we sat down and agreed on the standardizing of BIM objects, what values should be there, the format of these values, if he will input a certain starter, how this starter will be written, if it's a star delta or a direct line or whatever.

We agreed on these parameters and the format of the values that will be available in their model. And we agreed also that they will input these values before we tend to extract them automatically.

AUDIENCE: Is it able to recognize like when mechanical engineering has three motors when they're all [INAUDIBLE]?

AHMED ATTIA: You mean, it's the same thing as in one set, or the same thing as an error or a duplicate value?

AUDIENCE: Well, they'll have a motor called EF1 and then they have [INAUDIBLE] the same thing. [INAUDIBLE]

AHMED ATTIA: Actually, I already presented the part where we did the data validation part, if you saw it. One of these data validations was, is there any duplicated values of any of the mechanical loads?

But the part-- the other part for the single sets, you know mechanical engineers sometimes do these single sets of pumps, for example, and they work separately as one is a standby and one is a duty. So we agreed that we will have a certain value inside both that we can scan to know which one is duty and which one is standby. OK.

AUDIENCE: Pretty much just [INAUDIBLE]

AHMED ATTIA: Yeah. [INAUDIBLE] Yeah.

AUDIENCE: OK.

AUDIENCE: [INAUDIBLE] what parameters you extract from the mechanical family in order to get that information [INAUDIBLE] so in my case, mechanical engineering [INAUDIBLE] so mechanical engineering will use different parameters in their [INAUDIBLE] electrical data. So if I [INAUDIBLE] API function, then I'm calling up [INAUDIBLE] parameters but they vary based on whoever I'm working with. Have you ever had that--

AHMED ATTIA: OK. I will answer you from a totally different experience at Dar. We had this when we were-- we had our original tools before this one. Our original tools did do some automation of extracting [INAUDIBLE] schedule data without any analysis. And we needed all of our families inside the model to contain certain parameters.

And once, we were working with an external consultant. He did the lighting and we did the power part. So we needed them to have the same parameters. We simply gave them all of our families and combined with a guide to how to fill all the parameters and what are the default values that should be there so we can-- we can solve these discrepancy when we are working with multiple consultants.

We still have time. Any questions? Yeah.

AUDIENCE: So in the case where they do not want to use your panels because of their standards, you have a way to be flexible with, like, I can't take volts as a parameter, they put in voltage as their parameter again. So you just have-- can you just map it differently to extract [INAUDIBLE]?

AHMED ATTIA: You mean, can-- if there is already a difference, can I solve this somehow during the coding process? This is your question?

AUDIENCE: Yeah. [INAUDIBLE] the tool you already have.

AHMED ATTIA: Actually, the Revit API does not offer that. It's pretty much about extracting only the values that we stored there. But when we had a similar problem, we agreed that we might list-- but this is not done yet.

We agreed that we will do a list of GUIDs of all of our parameters. And each GUID will express a certain value. This GUID might be the starter, for example.

And we make sure everyone we work with, either in other trade or in other company, they can manually inside their shared parameter change the GUIDs to be exactly the same as ours. And then we have no problem. And through the API, you can pinpoint shared parameters only through the GUID so you get out of the difference of names. More questions?

AUDIENCE: First, the database that holds your reference, you're using Access. Do you distribute that to their multiple locations or is there-- [INAUDIBLE] we're talking about incentivizing [INAUDIBLE]?

AHMED ATTIA: Actually, that's why we wanted to move to cloud. We-- first we put the database into our server and everyone can access the values and come with the values and finalize their own analysis. But when we thought that we need to distribute this internationally to all of our offices, we had no choice but to move to cloud. So we started thinking to build our own private cloud to preserve security and the same time allow our solution to be more global. Yeah.

AUDIENCE: [INAUDIBLE] mechanical engineer [INAUDIBLE] or FLA or all these different values, but they won't always do it the same for sometimes the same type of equipment. So if that type of information that you're requesting isn't available to them-- for them easily on [INAUDIBLE] sheets, then how [INAUDIBLE] getting the right information [INAUDIBLE]?

AHMED ATTIA: You mean, the right-- the right information formats, or do you mean they don't know the value?

AUDIENCE: They don't know the value so it's not easily accessible to them without [INAUDIBLE] contacting the manufacturer or--

AHMED ATTIA: I don't think we faced that before. We always have a live connection with all of our manufacturers or all-- or-- of our local manufacturers in any country, so we tend to always have the required data. But this is part of the electrical and mechanical engineers code work when they are working on design criteria.

Where will we get these values? They might have their own assumptions. And based on this, they can input their assumptions to their models and work just fine. It will work just fine until the final output if we are-- we all agreed with the client that these are our assumptions, these are our values, we will think that these values should be like this and these values should be like this. But most of the time, we have all data available from any manufacturer around the world available to us all the time.

AUDIENCE: [INAUDIBLE] just go back to the manufacturer and get these specific [INAUDIBLE].

AHMED ATTIA: Yeah. Yeah. That's why we need the data sheets. Yeah.

AUDIENCE: [INAUDIBLE] How long does it take [INAUDIBLE] to develop the database?

AHMED ATTIA: Actually, developing the database was pretty simple. The complicated part was to sit together and think what to include in the database, where to get it, is it the right format. We faced some issues with the format of cable data tables. Some cable data tables look like this, some cable data tables look like this, so we needed to agree on a certain format.

So the hard part was to agree on it. But the database and tabulation was very, very pretty simple task. Yeah.

AUDIENCE: I guess in the world that I work in, a lot of the mechanical engineers that I work with don't understand wiring. So in this whole process, I mean, was there kind of a deal or whatever that you set up so that you could-- you can't-- with engineers, you have to understand electrical in order for this to work.

AHMED ATTIA: Yeah. That's the whole idea of automation. All of their work was to, OK, focus on these parameters, focus on their values, focus on their formats. And the data transfer, the calculation, the whole process will happen automatically so we don't have any problem. He will just focus on inputting his values, not just export some values into an Excel sheet and send that. And then I call him, what did you mean by this and what did you mean by that?

No, we agreed on a standard. We agreed that all-- actually, they worked a lot on their families and libraries to include everything we wanted and everything we might need in the future.

AUDIENCE: So for instance, I mean do they provide [INAUDIBLE] in volt amps, in horsepower in amps [INAUDIBLE]? Do they provide all that?

AHMED ATTIA: Yes. Everything, motor starters. We-- of course, we calculate the protection and feed requirements. But everything we might need-- even the question here when I was asked about the full sets of panels we needed of mechanical equipment, we needed to hold multiple meetings to agree what do we need exactly. What do we need available there inside our elements, inside our models, inside our templates, inside our project parameters so we never face the problem of, OK, we forgot this. This is missing.

But I need to remind you that this is an ongoing process. You will never get it the first time. We worked a lot to include some things that was not taken into account in the first place. You know, electrical analysis are a massive task. So you tend to-- OK, what if I put this? What if I put that?

We decided at some point to include two ways of calculating protection and feeder requirements, one from the IEEE and one from the IEC. So we needed to work more on our platform and coding and calculations. This is an ongoing process. But it pays off at the end.

AUDIENCE: Different cities and stuff adopt different versions of the [INAUDIBLE]. So how does the database [INAUDIBLE]

AHMED ATTIA: Actually--

AUDIENCE: [INAUDIBLE] how do you select the correct version [INAUDIBLE].

AHMED ATTIA: Ah. Actually, you chose a very specific case. The NEC is only specific to North America and the USA. But in the Middle East and most of Europe, we never use all of the NEC. We tend to reference the NEC in some cases.

But we don't use the NEC. We use other regulations. So the difference between these regulations are in formulas. So we can include multiple formulas. The difference between these regulations are in the reference tables, so we can include both reference tables at the same time.

But if we thought to include the NEC, I think it will be slightly harder, since it's a different structure of analysis. But when we are thinking of the IEE, the IEC, our own local regulations in the Middle East, they all align somehow. So what we needed to do only to include all the formulas that we need, either it's from this source or this source, and also include all the calculation references regardless of where-- which code are they from.

And then through the settings, we can filter what we want to reference and do the right analysis through it. OK. Hope I answered you. More questions?

AUDIENCE: Will your three-minute video be available?

AHMED ATTIA: The three-minute video-- actually, I-- before the session, I tried to upload it. But there was some complication. So I'll be more than happy to send it to you after the session. Yeah.

Any more questions? OK. Thank you so much.

[APPLAUSE]

AUDIENCE: Thank you.