Storing PLC Data in SQL Server database
Let's start with the basics:

Should you store 16 trillion raw data points per year in a relational database? Probably not. Think about what you're going to do with it afterwards, and what those queries will look like. Relational databases are great for data that has relationships to other tables and needs to be inserted/updated/deleted frequently, or read by common reporting tools, but it's not quite as good of a fit here.

If you don't do it in an RDBMS, where do you do it? Meet the time series database, something designed for this exact purpose. Examples include Graphite and InfluxDB.

If you had to do it, what should you look out for? Any kind of maintenance will be extremely challenging - index rebuilds, stats updates, backups, CHECKDB, etc. Instead, consider a dynamic sharding design where data is split into smaller volumes. In the data warehousing realm, for example, large tables are typically split by date range (2017Q3, 2017Q2, 2017Q1, etc) so that if you need to add new columns for new incoming data, you only have to modify the current table. For reporting purposes, you can union all the tables together into a view - but just be warned that any kind of ad-hoc queries on a trillion-row table can prove challenging. (Heaven help you if someone wants an order-by and there's no supporting index - goodbye, tempdb drive space.)