I would consider a network design that brings along overlapping addressing *by design* harmful. Avoid it like the plague. In new/fresh designs, avoid NAT. Imagine the pain when you discover that one of the applications does not cope well with NAT and/or port forwarding. 


I would suggest (and now this is getting opinionated, hence possibly off-topic)

Use some features only IPv6 can offer, and go IPv6-only for a modern network. 

 - each module gets an IPv6 capable router as entry/exit point towards the common network.
 - towards the module, the router exposes as many VLANs/subinterfaces/subnets as needed, to accomplish the inta-module split of business/data/control "zones". Some rough-hewn access-lists or a firewall (e.g. ZBFW, if it's a Cisco) ensure that traffic cannot be forwarded between zones, but only to/from the central network (or the respective "zones" thereof).
 - the router acts as DHCPv6-PD (prefix delegation) client towards a DHCPv6 server in the common network, requesting the delegation of a suitably sized IPv6 prefix. 
 - using appropriate mechanisms (i.e. a dynamic routing protocol), the central network then ensures that routing information for the freshly delegated prefix is disseminated appropriately (i.e. all routers participating in the common network eventually know that prefix `2001:0db8:000a::/48` is now reachable via router "A" and they know how to reach router "A" .) There are many different ways to accomplish this, all depending on how the common network is built (a flat LAN? a somehow emulated/stretched broadcast domain instead of a LAN ? PPPoE Sessions to a number of concentrators? a bunch of serial lines with PPP? an MPLS L3-VPN? Some MetroEthernet L2-service by a carrier? ... the possibilites are endless).

The router and the given module's systems then ensure that every system within the module gets predictable IPv6 addresses. 

 1. Either by being a stateful DHCPv6 server, assigning leases as <DelegeatedPrefix>+<predefinedHostID> (although, that might be a bit of a topic there, configuring a stateful DHCPv6 server with a DHCPv6-PD delegated network prefix and just the HostID part being preconfigured/fixed)
 2. or by implementing something like Linux's [ip token][1] on the end systems, where the end system does SLAAC to learn the current subnet prefix, but then tries it's own manually predefined HostID, performs DAD with that and brings up the IPv6 interface. 

But that should stop there - and this is now leaving the scope of networkengineering somewhat...

Some DNS magic might be required. Once the central DHCPv6 server assigns prefix `2001:0db8:000a` to router "A", it could proceed with a script that generates a set of pre-known AAAA records like `<oneOfTheKnownEndSystemNames>.moduleA.internal.myscadanet.tld`, with each a ressource record of `2001:0db8:000a:<moduleInternalSubnetid>:<givenHostID>`; that's probably best done with DDNS (research topic: [Dynamic DNS updates][2], not the DynDNS style HTTP update thing). That script may reside on the DHCPv6 server itself, which would in turn be the only system allowed to DDNS-update the neighboring DNS server.

Hm. A bit on the progressive side, all of this. But still - this is the 2010's. IPv6 is a thing. Talk to your vendors. 

  [1]: https://www.systutorials.com/docs/linux/man/8-ip-token/
  [2]: https://en.wikipedia.org/wiki/Dynamic_DNS