In recent years Ethernet has proliferated as the network of choice for running automation on industrial, utility, ITS (Intelligent Transportation Solution) and military sites. In some cases sites have been upgraded slowly, with a main backbone being put in place and then extended to provide network coverage for edge devices. In other cases the full network for the site will be planned and implemented, either all at once or as a series of upgrade phases. In both cases proper planning of both the physical and logical networks is required. Oftentimes these networks will be thrown together in a haphazard manner, which inevitably leads to problems in the future as the network grows. For all networks, and especially mission critical networks, proper planning and implementation will allow for a stable, reliable network, meaning less downtime caused by the network and less headaches for engineers and network administrators.
One of the first, and most important, elements to designing a network is proper communication. As network design is most commonly outsourced to a third party company of network specialists, care needs to be taken that miscommunication of the requirements does not lead to a network design that is unfeasible for the project. Another aspect that can lead to a suboptimal network design is assumptions. Although it seems quite obvious that the person designing the network should not make any assumptions about the customer’s requirements, it still happens all too often and all too easily, which again can lead to the network not being able to handle the requirements. For this reason constant communication at each step of the network design must take place between the design team and the customer.
The first step in designing the network is to design the physical aspect of the main backbone of the network (Backbone switch locations and cable reticulation) based on redundancy and throughput requirements. The design team will need to determine where each backbone switch will be located physically. In some cases this is quite straightforward, such as in a mine with multiple levels (Backbone switch per level) or when linking up countrywide sites such as substations (1 backbone switch per substation). One of the most important aspects to consider at this point is the distances between each backbone switch, and by this we refer to the actual distance the cable will travel (As this will generally be further than a simple straight line between the switches). Typical vendors can run fibre over distances ranging from a couple of meters up to 115km, depending on whether you are using multimode or singlemode fibre, and depending on whether you need 100 Mbps or Gigabit speeds. So keeping this in mind the design team will look at all the required backbone switches and put together a physical backbone topology for the network. At this stage the design team must also take into account the required redundancy on the network, and make sure to cater for enough links to provide a network that can recover from any single, or multiple, cable breaks. A question that the design team of H3iSquared will often pose to a customer is how much redundancy can you afford NOT to have. Each backbone switch location will need to be checked to see what kind of impact on the network will be experienced if that switch, or one of its physical connections, was to fail.
The next step is to start looking at each section of the network containing a backbone switch, and the end devices in that area. We need to determine how many devices will need to connect at each backbone switch, as well as what type of connection each device will need (Copper/fibre cable, 100Mbps or Gigabit etc.). At this point it helps to make a spreadsheet for each node, with a total count of all the ports that will be required at that section. It is also important to keep in mind how the uplinks between different switches in the network will be connected, and how many uplinks will be needed per switch (Uplinks are connections between switches, and can sometimes be overlooked when planning for port counts). Also do not forget to cater for future expansion at this point as well.
Once we have this basic port count (Which may change slightly over the next couple of steps) we need to look at the bandwidth requirements within and between each node. Generally end devices will not need more than 100 Mbps, however the backbone will often, if not always, need to be higher than this. To work out bandwidth requirements we will need to know what devices are in each node, how much traffic they will be sending at their peak, how often and for what duration they will be communicating, and what the minimum latency requirements are. For instance a PLC that is sending constant readings back to a control room may use very little bandwidth to send the data, but will be sending constantly. A VoIP (Voice over IP) phone on the other hand may send slightly more traffic than the PLC when it is transmitting, but will not be sending on a constant basis. A good rule of thumb is to always allow for a worst case scenario (With all devices in a node needing to transmit across the main backbone at once). Although this may be a very unlikely scenario, it is a possibility and so must be catered for. Once we have an idea of the bandwidth requirements we can decide what total bandwidth we want available on the backbone. Once we know this we can finalise the port count required for uplinking the backbone switches together.
At this point we are ready to decide what equipment to use for the network. Simply select switches from your available product range that will cater for the port counts and bandwidth requirements that have been calculated. Always remember to cater for uplinks between switches as well as for future expansion of the network!
Although it may not always be part of the project scope, there are more elements that need to be catered for when designing a network, i.e. the logical design of the network. This includes aspects such as IP addressing structure, VLANs (Virtual Local Area Networks), routing tables and network security such as authorisation, firewalls and anti-virus software. This is out of the scope of this article, but will be covered in the future.
For any further questions or information regarding network design, implementation and the RuggedCom hardware and software range please contact H3iSquared directly.
Tel: +27 (0)11 454 6025
Email: info@h3isquared.com
Web: www.h3isquared.com