Knowledge to Code, Code to Documents

By: Gabor Kovacs, Software Development Team Lead

Have you ever wondered how IT can do multi-disciplinary engineering tasks, reducing weeks or months of work to just an hour? We will explain the process to automate this, what resources are needed, and wins and struggles we see during the implementation.

Although the Transcend Design Generator (TDG) has a wide range of treatment options for a wastewater treatment plant, there are still other options available in the market. In this blog I will talk about a brand new – and of course not real – option, which provides a new primary treatment option called the Transcend’s Primary Sieve (TPS). This will serve as an example for integrating any other technology or equipment anywhere in the system, for which the configuration of TDG is usually a similar process.

At the start, we need to decide who should have the TPS as an option in the system. When we collaborate with a client that is a technology supplier or manufacturer that have their own treatment units, we usually only make that system available to them, along with any other third party (for example a utility) that they want to make it available to.  However, when we are doing more generic extensions (e.g., not proprietary technologies), we try to make it available to a wide range of customers, including it in the base TDG platform.  We must also define a clear scope of work. Some units are only useful with special conditions from the start above a certain flow, for specific influent or compliance needs, or only work in tandem with other specific solutions or technologies. Since we do not have these at the start for the TPS (because we made it up!), we can move forward.

The first engineering step is research and development. Our process engineering group tries to create a model of input variables and output variables that can do the unit sizing. This only includes volumes or surfaces, not exact equipment, and focuses heavily on providing solutions to a wide range of input and output values. At this point, engineers will disclose to the client mandatory and optional inputs, as well as the details of the sizing solutions. In many situations, working with a manufacturer means they have their own calculation to size their system, but we still need to adjust it in our system. When we have a client specific solution, we usually discuss the details with them, but for the TPS, since it is generic, we will not. Let us assume that both the cleaning factor for specific state variables and the sizing based on the surface of the sieve are calculated.  At this point, we have a specification for the process calculations, and the input and output variables.

The next steps can be done in parallel but let us go in the order the end-user will see them.  We first need to create a specification for the UI changes the customer sees on the input side to make this system work. We then need to create a model for our internal solution, the Plant Graph, where this unit is in the WWTP, what it is connected to, and what kind of mechanical, equipment and/or civil requirements it will have. This means that we will ask our mechanical and civil engineers to investigate the provided values from the process, and in case anything is not clear we will discuss it with them. We can have multiple iteration on these steps since the civil engineers’ needs might require some other data points for a proper sizing, which might not be calculated, or never even asked from the user on the UI.  As the last step in these parallel parts, our engineers create extensions for our text-based documents.  For example, what kind of data points do we want to show in the Technical Description for the TPS. After all this is done, we have a complete specification, but nothing is developed yet.

Our development team can now look at the specification, raise any questions (there are ALWAYS a lot of them!) and discuss the steps needed with the engineers. In some cases, that means we will change the specification to provide more generic solutions for the future, specifically regarding UI changes. The developers might raise questions which points out a specific solution that was not managed in the specification. For example, one of the developers asked “how do we design Primary Sieves when the user said, they have existing primary clarifiers? Are we designing these before or after those, or we ignore them completely?” When these questions are raised, we usually take the MVP mindset for a quick solution. If we work with a client this is something we will ask them and extend the specification based on their items. One every frequent solution is that we do not allow existing solutions for these units at first. After all the questions are answered, and all issues solved, we can start the actual development.

We always start with the UI and process development, like how it started on the engineering side, to allow our expert testers to start a wide range of projects even before anything else is done, which helps our testing regime a lot. Of course, questions can be raised during this step as well, and sometimes we find out some edge cases. For example, let us say existing trickling filters were not discussed previously but needs to be adjusted in the specification. This would be discussed with the manufacturer or client or engineer, and we might rethink some other steps. The reason we do not start all developments at once is to avoid these specification changes and rework the same solutions multiple times in all parts of the system. We finish this part with validating the process results based on our calculations and expert tests, and if the process side is implemented correctly, we can move forward.

Next, comes the development of the graph-based solution, which is a detailed data point aggregation. You can imagine the development here is exactly how a mechanical or civil engineer would think. The requirements are a surface area for the sieve, and we will select how much equipment will be provided in this area, and what buildings we need to account for. This sounds very straightforward, but we extend our database of equipment with various solutions, test the reality for solutions for very low or high flow, and also need to think about the actual viability of a solution. For example, nobody wants to create a concrete tank of half meter to half meter, with a depth of five meters. Civil and mechanical steps are iterating around each other since some civil sizing needs to know the size and location of the equipment inside – think about a blower building – but it can also be the other way around, where we design the civil construct first, and later we add an equipment to support it – like a primary clarifier, and then the bridge.

The step before was complicated, but what is remaining on the development side is much simpler.  We already have a generic solution to convert the graph mentioned above to documents like Equipment List, Process Scheme, or a 3D Building Information Model. We might still need to adjust or add a new BIM object to the solution, but the major steps happened already. To finish the development, we extend the text-based documents as well.

You might think at this point, the solution is ready to show to our users. However, we need to ask our expert testers (engineering), and our quality team to start a lot of projects in order to test their outcomes. We will realize edge cases in this step once again, or sometimes just some validations, that we forgot to set at the start. For example, the TPS is only going to be available above a certain average flow since it will not make economic sense w/ proper equipment and a civil solution below that threshold. If we work with a manufacturer, we like to include them at this step to provide some typical inputs and designs as well. When this complete, we are ready to ship the product to our previously decided user group.

We hope this blog provided insight into the thought put into generalizing engineering solutions just for one small unit at Transcend. Although, you cannot try out the TPS, you can review other units added to the TDG. Click here to run a free design in the system to see how we turn knowledge into code and code into engineering documents.