Your description and code snippet does not provide enough context for an external person to understand your intent. Please, provide more context and possibly a sketch of you system architecture so that the code snippet can be correctly interpreted.
What do you mean by "to change the values of my ports"?
If each layer differs from the previous, what is a point to use a loop instead of a simple to understand sequence of statements?
Do you really need to expose the reader to so much details (i.e. 26 layers) to describe your problem? Try to reduce your example and enhance it with enough context so that we get a better idea of what you want to achieve.
You seem to be not yet enough familiar with the fundamental concepts of SystemC. Consider to read a good introductory book to SystemC!

Your example code uses many features, which have been deprecated for good reasons already in IEEE Std 1666-2005. The Accellera proof-of-concept implementation SystemC 2.3.2 of IEEE Std 1666-2011 continued the effort to improve the code quality and facilitate the maintenance of the implementation by removing long-deprecated features and improve the compatibility with modern C++ compilers and coding techniques. I recommend that you familiarise yourself with the "Modern C++" concepts introduced by C++'11, '14, and '17 and start to modernise your SystemC models. Following are some hints to get you started:
Use the <systemc> header instead of <systemc.h> and explicitly use the appropriate namespace prefixes or using statements
Use std::string instead of the long deprecated sc_string
When calling sc_core::sc_start(), always pass the appropriate time unit as second argument or pass a sc_core::sc_time constant/variable
Make sure to compile your model with the same flags that were used during the compilation of the SystemC library itself. Especially make sure that everything is compiled against the same language standard! Otherwise, you will face link problems!
Besides a good book on C++, I also recommend you to read a good introduction to SystemC, e.g., "SystemC from the Ground Up".

Then, you have to express the vectors as an appropriate data type, which fulfils the conditions for the template parameter T of the port/bound signal (cf. to clause 6.4.3 of IEEE Std 1666-2011), i.e., the data type needs to implement the equality operator==, stream operator<<, and assignment operator= as well as a default constructor. E.g., you could try to use a suitable data type from the Eigen library.

This kind of functionality needs to be implemented by your VCD trace file viewer. E.g., the impulse plug-in for Eclipse available from toem.de seems to offer this kind of functionality in its "analyze" variant.

impulse is a good trace file viewer for visualising the results of simulation runs of SystemC models.
"scv" hints that this format is not part of the TLM standard, but part of the SystemC Verification (SCV) library, which you can also download from the Accellera website:
http://accellera.org/downloads/standards/systemc
The SCV tar ball contains in the docs/ directory several PDF documents, which outline the use of transaction recording. As you can guess from their publication dates in 2003, this mechanism predates TLM-2.0. As I never used that API myself, I cannot provide further insight/guidance.

If you insist to instantiate 16 separate ports to transfer each array element separately from each other, you will also have to write/read the elements in your code one after another using, e.g., a loop over the array. From a simulation point of view, all writes will happen at the same time.

Signals constitute the communication channels between your models. However, in almost all cases, you should avoid to read/write them directly. Signals are meant to be bound to ports, which constitute the interface of your modules. The read() and write() member functions of the ports are the primary functions to reading a value from the port or writing a value into it, respectively. As you can see from the class definitions of the ports in the SystemC LRM and SystemC AMS LRM, the ports do provide depending on their input/output direction overloads, which allow them to be used in most cases like a regular variable for reading and writing:
sc_core::sc_in<int> de_in;
sc_core::sc_out<int> de_out;
sca_tdf::sca_in<double> tdf_in;
sca_tdf::sca_out<double> tdf_out;
...
void my_proc() {
int ivar;
double dvar;
ivar = de_in;
de_out = ivar;
dvar = tdf_in;
tdf_out = dvar;
}
Though, using the read() and write() member functions of the ports is the recommended practice as this makes it explicit that you are accessing a port instead of a variable. As this questions touches very basic concepts of SystemC (AMS), I recommend you to read a good introductory text on SystemC and SystemC AMS.

As SystemC is just a C++ library, you can pass in and out information to your model by many different means. Command line arguments are just one option. Another simple way is using the standard input, output, and error streams. You can also use sockets and named pipes. The interface to your outside world should be also properly represented in your SystemC model, e.g., by dedicated stimuli and monitor modules, which open up the required communication channels to the outside world and handle then the synchronisation. In its most simple form, you can just use blocking reads and writes to your communication channel. You may also need to cease execution to the SystemC kernel to advance simulation time using wait().
What you are asking for seems quite standard for many co-simulation scenarios and there have been many papers about this.

It is hard to guess a reason for the segmentation fault from the information that you provide. Have you tested that your simulation works properly if you convert the time range, which you passed in us/ms/sec to ns?
You should also check out the core dump in the debugger. It contains a stack trace so that you can check at which point in the execution the segfault was provoked. Of course, the segfault might have occurred in some internal/standard library function, but in many cases the cause for it happened in user code. Therefore, you will have to step up stack frame per stack frame until you reached the code you have written. While doing this, examine the arguments and local variables of the current function. They might give you a hint what is going on.

Your point 1) to 4) should typically be implemented in your sc_main(). Note that you can pass into sc_main() command line arguments in the same way as you can do in plain C into main() via the argc and argv parameters. This would allow you to set up your simulation differently according to the passed parameters.
Note, you don't need to call sc_main() multiple times to just change the value of a signal. An sc_signal has a write() member function, which you can call from sc_main() to update the signal's value and then continue simulation by calling again sc_start(). However, using this approach for anything but the most simple stimuli (e.g., for generating the truth table of a combinatoric circuit) becomes very tedious. Instead, stimuli should be generated from some dedicated stimuli process. Note that a TDF module is usually the best and most performant choice for generating an arbitrary stimuli for a ELN/LSF model.
Regarding your planned use of the SystemC AMS model as a shared library: Please note that the SystemC simulation kernel of the Accellera proof-of-concept implementation cannot be restarted once simulation has been finished with sc_stop(). This is a long standing issue caused by the fact that certain allocated resources by the kernel are only freed once the whole OS process executing the SystemC kernel has been terminated. As long as your shared library will stay in memory, this is not the case. Therefore, you won't be able to do another elaboration and simulation.
I suggest that you have a look at a good introduction book on SystemC (e.g. "SystemC from the Ground Up") and the SystemC AMS User's Guide to learn more about how to set up test benches in SystemC.

Without a minimal self-contained example exposing your problem, it is hard to give an answer to your question. Did you set besides the data pointer also the data length correctly in your instance of the TLM generic payload?
By the way, in C++ and SystemC, you should not use malloc() and free() to allocate/deallocate raw memory, Instead, you should prefer to use an appropriate container or C++'s new/delete operators as a last resort.

Your problem description is a bit contradictory: If you would call your SystemC application as a new process from a really extern C program, there should be no problem as you describe it. However, if you actually mean that you have implemented your own main() function and linked it together with your SystemC application (i.e., sc_main() which instantiates your SystemC model), then you are not allowed to directly call sc_main() from the main() function! Instead, you have to call sc_elab_and_sim(argc, argv) to start elaboration and simulation of your SystemC model. After some preparations, sc_elab_and_sim() hands over control to sc_main(). See clause 4.3 of IEEE Std 1666-2011 for more details.
A minimum complete example exposing just your problem would help to give a better answer.