You can't do this through generic OBD-II. Take a look at acceptable OBD-II queries by mode. There is nothing there to provide information about how the vehicle is constructed. That's not to say that some manufacturers may not have proprietary undocumented commands, but those aren't generally available, and certainly can't be relied on to be present, or used safely in all situations.
It makes sense. The modules you identify, while their presence is a typical solution to various engineering challenges, aren't really "standardized" in any way (sure there may be some commonality between, say, "suspension control modules" in similarily designed vehicles, but, philosophically, at no point was a "suspension control module" ever defined as "a standard, optionally present component of any vehicle"; it's just a vague thing that somehow controls suspension-related things in an arbitrary way in effectively random vehicles -- as opposed to some common optional component with a standardized OBD-II interface and a standardized bit in an ID field somewhere).
(Here's some food for thought: What exactly is a "module"? Anything wrong with saying "this vehicle has a power seat adjustment module"? If so, why? If not, what are the actual implications to your OBD question? You see, it's not as clear cut as you think.)
The ECU is a black box; what happens behind it isn't any of OBD-II's business as long as it conforms and gives meaningful responses to OBD-II queries. This is by design, it allows diagnostics tools to have a huge amount of flexibility and tolerance for a wide variety of vehicle technologies.
Also this info isn't really needed for diagnostics. OBD-II gives you information that isn't necessarily easy to determine otherwise. It's easy enough for a technician to say "Hey the car I'm working on right now has some sort of traction control management system," because they hopefully know the basics of the vehicle they're working with. There isn't a driving need to have the car's computer tell them that any more than there is a need for OBD-II to report the exterior paint color.
That said there's a couple things you might be able to do:
- OBD-II can report the VIN (assuming it's been properly set and not e.g. swapped out but not reset) and some info about the ECU name and version. You could perhaps glean some info from the VIN (Honda, for example, encodes various bits of info in their VINs - from this you could, say, determine with reasonable accuracy if a Honda engine has VTEC [heck, call it a "VTEC module" if you want... doesn't matter] or not), or build up your own database of various vehicles and cross-reference it with VIN/ECU info, etc.
- The presence of some PIDs can give hints about certain things:
- For example, if turbocharger related PIDs are present we can deduce that the vehicle probably has a turbocharger (or at least, some related technology where turbocharger parameters still make sense).
- Another example: We can guess what type of intake sensor it has (MAP vs MAF) based on what is reported (but even that is not for sure, because perhaps the intake uses some not-yet-conceived technology to measure air flow and/or pressure, OBD-II only cares that the ECU provides meaningful values).
- If you do happen to get your hands on some proprietary PIDs or other commands, you can e.g. check the VIN or ECU name first (say, to verify that it is a Mahindra before sending proprietary commands), then make judgments based on what you know about that particular vehicle and the responses to the proprietary codes.
More importantly, why do you want to know this information? There may be another way to achieve whatever it is you are trying to do.